On Mon, Feb 13, 2023 at 10:39 PM Arthur O'Dwyer wrote:
<snip>
> (B) Define what it means to "prevent" a call. This has not been addressed at all.
<snip>
> Frederick needs to describe the semantics of his new synchronization primitive in the same sense. Who blocks, how do they get unblocked, etc.
<snip>
> (Frederick has also said things like "The block only applies to..." which makes me think he's unclear on the English jargon meaning of the verb "to block"/"to wait" in concurrency in general.)


I was using the verb 'to block' as we use it in everyday language
(i.e. to block/prevent/stop/avoid something happening). I wasn't using
it in the very precise IT jargon sense of "The 'read' function blocks
until N bytes are available" -- although given that this mailing list
is for computer programming, it makes sense to be specific and choose
jargon over everyday speech.

Did you see the "-1" in the original subject line? That's where you
specify the return value when a re-entrance is prevented. To answer
your question: When re-entry is prevented, it simply returns -1. The
second attempted invocation is simply 'skipped' so to speak.

I was writing a desktop GUI program which had a button that when you
clicked it, it did a little data processing (less than a second's
worth), spawned a new thread, and then displayed a modal dialog box
until the new thread was finished. If the user was fast as lightning,
they could click the button twice really quickly in succession, and
the event handler that spawns the thread would be re-entered. To stop
this happening I used an atomic_flag to prevent the reentry, and so
the second clicking of the button was totally ignored. It would have
been nice to just write 'noreentry' after the function's name, hence
why I posted here with such a proposal.