[Vm-dev] linux build stability
Eliot Miranda
eliot.miranda at gmail.com
Mon Feb 7 19:18:14 UTC 2011
On Wed, Feb 2, 2011 at 3:07 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> >
> > Or some concurrency issue, because hearbeat runs in separate thread
> > than vm thread.
>
> Hmmm... That's a thought. This is a complete shot in the dark, but the
> following does not look thread safe to me:
>
> static void
> high_performance_tick_handler(int sig, struct siginfo *sig_info, void
> *context)
> {
> static int tickCheckInProgress;
>
> if (tickCheckInProgress) return;
>
> tickCheckInProgress = 1;
> checkHighPriorityTickees(ioUTCMicroseconds());
> tickCheckInProgress = 0;
> }
>
> This should be using a mutex, no?
>
Indeed it doesn't look thread-safe, and it isn't, but it doesn't need to be.
It is a signal handler whose sigaction does not contain SA_NODEFER and so
it cannot be reentered since the OS guarantees not to deliver the signal
until any previous instance of the handler has returned. Hence CAS is
unnecessary, but a good comment isn't :) I'll try and comment it here
rather than where the sigaction is established:
ticker_handler_action.sa_sigaction = high_performance_tick_handler;
/* N.B. We _do not_ include SA_NODEFER to specifically prevent
reentrancy
* during the heartbeat. We /must/ include SA_RESTART to avoid issues
with
* e.g. ODBC connections.
*/
ticker_handler_action.sa_flags = SA_RESTART | SA_ONSTACK;
sigemptyset(&ticker_handler_action.sa_mask);
if (sigaction(TICKER_SIGNAL, &ticker_handler_action, 0)) {
perror("ioInitHeartbeat sigaction");
exit(1);
}
best
Eliot
> Dave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110207/3141b655/attachment.htm
More information about the Vm-dev
mailing list