Signal handler & mutex, condition

[Marek Prochazka]

> Why? Just start single dedicated thread that waits for any of events
> from your timers, then invokes handler depending on particular
> event. You get 32 different events/handlers easily.

I need my timer events to be executed concurrently, which means that
each timer callback must be called in a separated execution thread. So I
need a pool of threads anyway. Having a single dispatcher thread then
brings a problem of mutual exclusion when accessing the thread pool,
which priority to assign to this dispatcher thread, etc. It all is
doable, but SIGEV_THREAD was added to POSIX to deal exactly with this
sort of problems.

> Anyway, I meant that RTEMS doesn't actually restrict you in 
> this regard,
> and while it doesn't provide ready to use solution for this particular
> application, it provides enough to achieve the goal.

Yes, perhaps. But my application was meant to be POSIX-compliant. I can
have a pool of pthreads and do manage the SIGEV_THREAD-like execution
myself, it is just more work, less efficiency, etc. But yes, I agree, it
is all doable, I was just checking whether 1) RTEMS timer handlers are
unrestricted and 2) SIGEV_THREAD notification is there. Answers to both
questions are no, and only solution to do "unsafe" stuff (e.g.
synchronisation) within timer handlers is to create separate threads.

Thanks,
Marek