Atomevent

[spe-ciellt]

I have extracted the atomevents updates to a separate branch, else there was other non-relevant stuff. Hence the slightly odd branch name.
What an event is is hopefully documented using doxygen in atomevent.c.
Comments are welcome.

[tidklaas]

If I may offer some thoughts on this implementation...
I do not think it is very elegant to have the event source signal the receiving thread directly for two three amongst my reasons are:

1. This is mainly my personal preference, but I just do not like handing around vital data structures like TCBs unless it is absolutely necessary.
2. Signalling multiple threads for the same event is impractical. The event source has to keep a list of subscribed threads and provide an interface for threads to subscribe and remove themselves.
3. Unless a thread is removed, its event mask can be modified by the sender, even when not currently waiting for an event.
4. There is only one global set of event signals and extreme care must be taken that the bit definitions are unique.

Somewhere in my heap of ProjectsIWillTotallyFinishOneDay™ I have an AtomEvent implementation based on an event "object". Receiver threads register with a mask of requested signals and are suspended on a wait queue until a sender triggers the event object with a matching signal. Senders do not know which or how many threads are waiting and receivers do not get touched unless they are currently waiting on a given event. Bit definitions for the signals depend on the event context only and need not be globally unique.

I did not submit it because that code tree was already heavily modified to begin with (linked list code replaced with list macros from Linux kernel, whole project run through indent etc.), but if there is interest, I could dig it up again for reference.

[spe-ciellt]

Thanks for your input.
Your points are valid, though my goal for my atom event implementation was to implement this very simple type of events.
The inspiration comes from embOS, which has a similar operation [1] and I have used it in previous projects a simple mechanism to signal an interrupt to a thread. The thread does what the interrupt routine supposedly do, but not in an interrupt context. This is because some chips have one interrupt pin, but requires a lot of processing.
Also simple protocols which sends a byte, waits for an interrupt, then send next byte and so forth can be implemented easily. I have actually used semaphores for that so far.

Some short notes on my intentions:

• Signalling an event to several threads is not the idea.
• I never remove any threads because of the same reason as I never use malloc/free (or similar scheme) in my embedded designs.
• The event bitmask is global in the thread sence, ie one event mask per thread.

The type of events you describe I think it is the type FreeRTOS has. Maybe I should rename this to something else so the name atomevent is still free?

[1] To Segger lawyers; I have never read any actual Segger code, it is only deduced from manuals and API code.

[tidklaas]

Yes, you are right. My concept of an event has always been a kind of broadcast that anyone interested can receive. Your implementation is more like sending a signal to a single task in a UN*X environment (e.g. kill -USR1 4711). So maybe signal would be a better name for it?

[FilkerZero]

I have a "FreeRTOS" event cluster workalike for AtomThreads that I wrote a few years back (without reference to the FreeRTOS version), and I didn't call it "event", or even "signal" - I called it "flags". It is not part of my current AtomThreads fork on GitHub because, like @tidklaas, I had changed the base code by running it through the moral-equivalent of "astyle", but also made a number of other changes to "atomkernel.c" that would not work well for many people.