memory visibility and signals...

[Chris Thomasson]

Does the fact that a signal-handler has executed on a given thread guarantee
that a #StoreLoad memory barrier gets executed? I can't seem to find any
guarantee in the standard. I was wondering about this because I have a toy
PDR implementation with signals. I use them to detect quiescent-periods.
Something like this:

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/9545d3e17806ccfe

static ATOMIC_WORD_t g_epoch = 0;

void pdr_signal_handler(int sig) {
/* if a signal handler does not guarentee a membar,
then one needs to be added here:

MEMBAR();

*/

ATOMIC_DEC(&g_epoch);
}

void pdr_epoch() {
lock_registered_thread_list();

/* get number of threads in the list */
int count = getcount_registered_thread_list();

/* prime the epoch counter */
ATOMIC_ADD(&g_epoch, count);

/* signal each thread */
for each registered_thread as t {
pthread_kill(t, SIGUSR1);
}

unlock_registered_thread_list();

/* wait on the epoch */
while (ATOMIC_LOAD(&g_epoch)) {
/* exponential backoff */
}
}

Also, does pthread_kill guarantee that a signal-handler will be called? If
not, the above can deadlock if a thread can be killed before it executed the
signal-handler...

Humm...

--
Chris M. Thomasson
http://appcore.home.comcast.net

[Joe Seigh]

Chris Thomasson wrote:
> Does the fact that a signal-handler has executed on a given thread
> guarantee that a #StoreLoad memory barrier gets executed? I can't seem
> to find any guarantee in the standard. I was wondering about this
> because I have a toy PDR implementation with signals. I use them to
> detect quiescent-periods. Something like this:
>
> http://groups.google.com/group/comp.programming.threads/browse_frm/thread/9545d3e17806ccfe
>
>
>

[...]

AFAIK there are no signal implementations that deliver signals to running
threads. Also the siginfo datastruction is probably too large to be
atomic. You could throw in a sig_atomic_t to be on the safe side. Plus
anyone would have an extremely difficult time proving you could do anything
useful without release/acquire semantics for signaling.

>
> Also, does pthread_kill guarantee that a signal-handler will be called?
> If not, the above can deadlock if a thread can be killed before it
> executed the signal-handler...
>
>

You mean can a thread terminate with undelivered pending signals? Probably
yes. You should use exit and/or cleanup handlers to handle things.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.