sched/event: Replace semaphore with direct scheduler operations in event implementation to improve performance

[wangchdo]

Summary

The current event implementation uses semaphores for wait and post
operations. Since semaphores are relatively heavy-weight and intended
for resource-based synchronization, this is suboptimal.

So this patch replaced the semaphore-based mechanism with direct
scheduler operations to improve performance and reduce memory footprint.

This patch also introduce a new task state TSTATE_WAIT_EVENT to indicate
the task is waiting for a event.

Impact

improvement for the event module, no impact to other nuttx parts

Testing

ostest passed on board a2g-tc397-5v-tft (including event testcases)

[xiaoxiang781216]

but spinlock could avoid the global big lock, why do we switch back?

[wangchdo]

This is mainly for removing reliance on semaphore, after removing semaphore, we will use critical section to protect event, and spinlock is not needed any more.

The reason to remove semaphore is that it is too heavy for event timeout:

1. It has global big lock inside the sema_wait/sema_post api，so in fact there are double lock here: spinlock for event and critical section lock for semaphore
2. Semaphore object costs more memory
3. It has lost of logic inside sema_wait and sema_post that are not related to event timeout, these logic is even more complicated than event itself

Indeed the lock scope is very small in event, and after removing semaphore it is even smaller, so i think this would be better

By the way The current spinlock is also a global one for event post, it uses flags = spin_lock_irqsave_nopreempt(&event->lock) api.

How do you think?

[xiaoxiang781216]

why not continue use TSTATE_WAIT_SIG with alias

[wangchdo]

I think event is different than sleep... the main reason is for the function nxevent_wait_irq() I implemented and it is called from nxnotify_cancellation():

[wangchdo]

I prefer to introduce a new state TSTATE_WAIT_EVENT...... Because although the scheduler list is shared with signals, but in event case the task not only needs a timeout, it is also blocked on a new object — the event object and then in some cases the scheduler need to do special actions for blocked task is waiting on a event(to separate it from task that is waiting on a semaphore or just is waiting for a timeout(sleep wait or signal wait)), just like this XXX_wait_irq function for task cancel cases. This is similar to how a semaphore blocks a task on a semaphore object.