Signal handler & mutex, condition

Marek Prochazka Marek.Prochazka at
Wed Jun 28 11:06:48 UTC 2006

> 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.


More information about the users mailing list