Subj : threaded ticker design problem
To   : comp.programming.threads
From : Paul Braman
Date : Tue Jan 04 2005 06:59 am

I'm attempting to solve a problem I am having that deals with the
interaction of both threads and signals.  (Yeah!)

Consider an application that has two threads.  Thread 1 does work and
randomly queries a variable.  Thread 2 updates the counter when a
signal is delivered.

(The exact mechanics of how the signal is delivered and handled aren't
important, I think, as I have a good understanding of how to solve that
problem.)

I can cleanly write a query function for a multithreaded application
using the standard form:

{
pthread_mutex_lock (&mutex);
int c = counter;  // may be sig_atomic_t
pthread_mutex_unlock (&mutex);
return c;
}

However, it is the update function, which is called from a signal
handler, that presents a problem.  Looking at the list of functions
which are safe to call from a signal handler (POSIX), there aren't any
pthread_*() calls available.

I do note, however, the presence of sem_post().  I'm thinking it might
be safe to actually have *two* threads which handle the timer.  One
thread waits on the semaphore while the signal handler does a
sem_post() to notify it to increment the counter.

Anyway, thoughts on how this might be architected differently/cleanly
are requested.
Thanks!


Paul Braman
Paul<dot>Braman<at>NielsenMedia<dot>com

.