win32 SetEvent, ResetEvent and MsgWaitForMultipleObjects

 
Hi Eliot, Bert,

as part of reading the "goToSleep" primitive I had a look at Windows and the last time I dealt with win32 API was quite some time ago so maybe I am wrong but doesn't the time slice below look like a race condition? If not what am I missing?



VM Thread Socket Read Thread


ioRelinquishProcess..

  SIGNAL(pss->readSema)
                                 -> SetEvent(vmWakeUpEvent)

ResetEvent(vmWakeUpEvent)
MsgWaitForMultipleObjects...




Couldn't we have lost the vmWakeUpEvent for the socket and then wait the full timeout? The history in Opensmalltalk-vm doesn't go far but couldn't we create the vmWakeUpEvent with the autoreset flag?


thank you

        holger


Code snippets:



sqInt ioRelinquishProcessorForMicroseconds(sqInt microSeconds)
{
        /* wake us up if something happens */
        ResetEvent(vmWakeUpEvent);
        if (WAIT_TIMEOUT ==
                MsgWaitForMultipleObjects(1, &vmWakeUpEvent, FALSE,
                            microSeconds / 1000, QS_ALLINPUT))



int synchronizedSignalSemaphoreWithIndex(int semaIndex)
{
  int result;

  /* Do our job - this is now synchronized in signalSemaphoreWithIndex */
  result = signalSemaphoreWithIndex(semaIndex);
  /* wake up interpret() if sleeping */
  SetEvent(vmWakeUpEvent);



static DWORD WINAPI readWatcherThread(privateSocketStruct *pss)
{
  struct timeval tv= { 1000, 0 }; /* Timeout value == 1000 sec */
  fd_set fds;
  int n, doWait;

  while(1) {
...
        switch(pss->readWatcherOp) {
        case WatchData:
          /* Data may be available */
          pss->sockState |= SOCK_DATA_READABLE;
          SIGNAL(pss->readSema);

 

> On 31. Aug 2017, at 01:37, Holger Freyther <[hidden email]> wrote:
>
> Hi Eliot, Bert,

Hey!


> as part of reading the "goToSleep" primitive I had a look at Windows and the last time I dealt with win32 API was quite some time ago so maybe I am wrong but doesn't the time slice below look like a race condition? If not what am I missing?



> Couldn't we have lost the vmWakeUpEvent for the socket and then wait the full timeout? The history in Opensmalltalk-vm doesn't go far but couldn't we create the vmWakeUpEvent with the autoreset flag?

I looked at it again. First of all I think the MIDI Plugin should use an autoreset event for the midiInputEvent (as there is no call for ResetEvent).

Second I think we risk losing an event and then sleeping for the maximum timeout (and maximum might be indefinite in the future) but using autoreset might wake us up too early as well. It might be better to use autoreset but we can have something like this..


   WakeUp
   ...
   Smalltalk processes run
                <- semaphore signalled for I/O
                <- SetEvent...
   Smalltalk processes run
   IO will be handled
   Sleep...
     [Old call to ResetEvent that we should remove...]
   WaitForMultipleObjects

So in this case we would wake-up besides all events already being handled. Any idea how to move forward? Shall we try to do the right thing and use autoreset and monitor CPU usage?


holger