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
