[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