[Vm-dev] Why isn't signalSemaphoreWithIndex() thread-safe?

Eliot Miranda eliot.miranda at gmail.com
Sun Sep 20 20:00:37 UTC 2009


Hi Josh,

On Sun, Sep 20, 2009 at 12:43 PM, Joshua Gargus <schwa at fastmail.us> wrote:

>
> Hi,
>
> I've always assumed that signalSemaphoreWithIndex() must be thread-safe;
> after all, it's the "official" mechanism for notifying the image that an
> asynchronous event has occurred.  However, a pang of paranoia prompted
> me to actually look at the code, and it seems clearly unsafe.  This is
> bad, because I've been using it to signal events from separate native
> threads.
>
> What should we do about this?  It seems to me that it should be wrapped
> in a critical section, using the appropriate platform-specific
> synchronization primitives.
>

There's no need for this heavyweight approach because the VM can only
respond to these signals synchronously.  Instead we can use three variables
per index to implement an exclusion-free solution, thusly:

typedef struct { int lock; // accessed via e.g. XCHG to protect
signalRequest
                       int requests;
                       int responses;
           } ExternalSignalRequest;

ExternalSignalRequest *externalSignalRequests;
int checkExternalSignalRequests;

void
requestSignal(int i)
{
       while (!lock(&externalSignalRequests[i].lock))
             usleep(1);

       ++externalSignalRequests[i].requests;

        unlock(&externalSignalRequests[i].lock);

        checkExternalSignalRequests = 1;
        forceInterruptCheck();  // set a flag to cause the VM to check for
interrupts; in the stack VM this is stackLimit := (usqInt)-1;
}


The VM responds in checkEvents:

    if (checkExternalSignalRequests)
        for (i = 0; i < numExternalSemaphores; i++)
            while (externalSignalRequests[i]. responses
!= externalSignalRequests[i]. requests) {
                signalSemaphoreWithIndex(i);
                externalSignalRequests[i]. responses;
            }



> Thanks,
> Josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20090920/a40c0ea1/attachment.htm


More information about the Vm-dev mailing list