Jan Kiszka <[email protected]> writes:
> On 06.04.22 17:56, Philippe Gerum via Xenomai wrote: >> From: Philippe Gerum <[email protected]> >> >> The current implementation does not atomically consume+clear the event >> set to be received by the waiter(s), which makes it useless for >> anything but a plain one-time latch due to the race window this opens >> with a consume[A]->signal[B]->clear[A] sequence. >> >> To address this issue, let's provide the auto-clear feature with >> __cobalt_event_wait(). >> >> This change affects the ABI by adding the auto-clear mode as an opt-in >> feature, enabled by passing COBALT_EVENT_AUTOCLEAR to >> cobalt_event_init(). >> > > Makes sense, but shouldn't autoclear be rather the default then? Which > users are affected? None in-tree so far? > There is one user in copperplate: https://source.denx.de/Xenomai/xenomai/-/blob/28158391258eea52650856bef5d3ed6ebaaf813b/lib/copperplate/eventobj.c#L87 which indirectly affects rt_event_signal() from the alchemy API: https://source.denx.de/Xenomai/xenomai/-/blob/28158391258eea52650856bef5d3ed6ebaaf813b/lib/alchemy/event.c#L453 Nobody raised the issue so far with alchemy, which is why I refrained from turning the autoclear mode on by default so far. This is debatable, since no documentation explains the limitation on usage caused by not having the autoclear mode set. -- Philippe.
