No, it is guaranteed by the interpreter that the methods will run in that order. The problem appears here that that the OS is not immediately moving the waiting threads into the run state when the semaphore is posted such that the reset prevents them from being recognized as posted.
The other possibility is that the waiting thread, because of how oorexx cooperatively dispatches the threads, has not yet reached the point where it is actually waiting on the semaphore. This could cause the two method calls for the post and reset to get executed before the other thread is even waiting. This all comes down to how the OSes dispatch threads and handle semaphores. Factors that are really outside of the control of the interpreter. Erich will have to comment on what his intentions were with this testcase and whether adding the syssleep is ok. Rick On Wed, Aug 19, 2020 at 5:49 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote: > Maybe asked differently, the statement > > sem~~post~reset > > will cause the semaphore to be cleared by "post", which would allow the > blocked "wait" method to get into the run state. Is the expectation here, > that this indeed is deterministically set out? So, is it guaranteed that > after returning from the "post" method that the Rexx interpreter must first > check on blocked activities and if one exists will run it (if the guard > expression allows for it) before the the "reset" message gets processed > causing the "reset" method to run? > > Or put in other words: is it a possible and hence a correct behaviour that > the "reset" method gets run before the blocked "wait" method as is the case > e.g. in Linux causing this test case to fail there? > > If there is no guarantee by the interpreter that upon return of a method > it firstly checks all blocked methods and runs one of them if the > evaluation of the respective guard expression allows for it, then the > second part of the test case should probably be removed. > > ---rony > > > > On 18.08.2020 13:52, Rony G. Flatscher wrote: > > Having learned that running the test suite on Jenkins excludes the > "EventSemaphore.testGroup" as it causes a failure in "test_wait_concurrent" > (starting in line # 137) I looked up the documentation and the test on > Linux. > > It seems that the waiting activity is supposed to run after the semaphore > gets posted. The documentation says with regards to "post": "Sets the event > semaphore to the posted state. All suspended activities waiting for this > event are released. Activities calling the wait method while the event > semapahore is already in the posted state will continue executing without > getting suspended." > > However, resetting the semaphore immediately thereafter blocks the waiting > activity and makes it time-out. The documentation says with regards to > "reset": "Clears the event semaphore. During the time the semaphore is > cleared, any activities starting a blocking wait get suspended." > > It seems that on Linux doing a > > sem~~post~reset > > will cause the waiting activity to not have a chance to get dispatched (as > a result of the "post" message) because the immediately following "reset" > message will inhibit the waiting activity to run, causing it to timeout. > Leaving out the "reset" makes the test case work. Also, if inserting a > syssleep between the post and reset messages makes the test case succeed: > > sem~post > call syssleep 0.01 > sem~reset > > Would it be o.k. to change the test case accordingly (inserting a syssleep > between "post" and "reset")? > > ---rony > > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
