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

[Joshua Gargus]

Igor Stasenko wrote:
>  
> 2009/9/21 Joshua Gargus <schwa at fastmail.us>:
>   
>> Eliot Miranda wrote:
>>     
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> On Sun, Sep 20, 2009 at 1:00 PM, Eliot Miranda
>>> <eliot.miranda at gmail.com <mailto:eliot.miranda at gmail.com>> wrote:
>>>
>>>      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;
>>>                 }
>>>
>>>       
>> Am I correct that ExternalSignalRequest.reponses is never reset to zero,
>> instead eventually wrapping around?  That worried me for a minute, but I
>> see that it doesn't matter.  Neeto.
>>
>>     
>
> Nope, it does resets the counters.. see signalExternalSemaphores  method.
>   

I was responding to Eliot's proposal, not the existing code.  If I
understand properly, he's proposing to maintain a per-semaphore count of
signal requests/responses, so there would be no
"semaphoresToSignalCountA/B".

Cheers,
Josh