<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 22/08/2020 03:50, Kirinn via
fpc-devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e848d3e7-5251-84de-091e-2478e78dc394@mooncore.eu">When I
researched synchronisation behavior and wrote the wiki page
"Threads", I found that RTL events behave like this:
<br>
<br>
- When the event is set, a single waiting thread is released (in
FIFO order), and the event is automatically immediately reset.
<br>
- The event can only be in a set or unset state; multiple sets do
not stack. Even if the event is set twice or ten times, a single
WaitFor or Reset will change it to unset. This is a likely cause
for deadlocks.
<br>
- Because the event is automatically reset when a waiting thread
is released, calling ResetEvent is generally unnecessary.
<br>
</blockquote>
I can confirm this on Windows.<br>
<br>
- If I set the event, and then 2 threads enter WaitFor => only 1
thread resumes<br>
- If I set the event, and then 1 threads enter WaitFor, resumes and
enters WaitFor a 2nd time => then 2nd time does NOT resume<br>
- If 2 threads enter WaitFor, and I set the event (once) while they
are waiting => only 1 thread resumes<br>
<br>
<blockquote type="cite"
cite="mid:e848d3e7-5251-84de-091e-2478e78dc394@mooncore.eu">
For set/reset counting we'd need a semaphore instead of an RTL
event, but I don't think we have an actively supported semaphore
implementation at this time.
<br>
</blockquote>
I can solve the issue at hand without a semaphore.<br>
I just needed to know.<br>
<br>
<br>
<div class="moz-cite-prefix">On 22/08/2020 12:50, Sven Barth wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d1f7dbb6-75be-c311-7594-b00c849d160a@googlemail.com">On
Windows these are direct calls to the WinAPI functions
WaitForSingleObject and SetEvent (and the created event is an Auto
Reset Event), so you should probably take a look at the MSDN
documentation for them... <br>
</blockquote>
Indeed....<br>
<br>
<a class="moz-txt-link-freetext" href="https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-setevent">https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-setevent</a><br>
SetEvent<br>
<blockquote type="cite">The state of a manual-reset event object
remains signaled until it is set explicitly to the nonsignaled
state by the
<a
href="https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-resetevent"
data-linktype="absolute-path">ResetEvent</a> function. Any
number of waiting threads, or threads that subsequently begin wait
operations for the specified event object by calling one of the
<a
href="https://docs.microsoft.com/en-us/windows/desktop/Sync/wait-functions"
data-linktype="absolute-path">wait functions</a>, can be
released while the object's state is signaled.</blockquote>
<a class="moz-txt-link-freetext" href="https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitforsingleobject">https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitforsingleobject</a><br>
WaitForSingleObject<br>
<blockquote type="cite">The function modifies the state of some
types of synchronization objects. Modification occurs only for the
object whose signaled state caused the function to return. For
example, the count of a semaphore object is decreased by one.</blockquote>
<br>
On current Win10, it definitely only wakes one thread once.<br>
WaitForSingleObject gives semaphores as example, but does not say
which other objects it may modify.<br>
<br>
In any case, I can safely RTLEventReset the event in whatever thread
wakes first, and then immediately RTLEventSet it again (if needed).<br>
<br>
That should be safe. It should also work, for any OS, on which
multiple threads where released. <br>
(The last one will Reset, but not Set it => so it will be cleared
when all is done / in the use-case I am looking at)<br>
<br>
Thanks to everyone for the detailed responses.<br>
Martin<br>
</body>
</html>