[M3devel] purported condition variable problems on Win32?

[Rodney M. Bates]

I've begun looking at this.

On 07/05/2016 03:19 AM, Jay K wrote:
>   https://sourceforge.net/p/pthreads4w/code/ci/master/tree/README.CV
>

As for spurious wakeups, the M3 Thread.i3 documentation of Signal explicitly allows
this: "One or more threads waiting on c become eligible to run", whereas the posix
pthread_cond_signal, according to schmidt, "notifies one thread waiting on condition
variable cv".  As I recall, these (the M3 semantics) agree with the original
Brinch-Hansen condition variables.  So, for implementing posix CVs, this would
be a true bug, but not so for M3 Thread CVs.

>   vs.
>
> http://www.cs.wustl.edu/~schmidt/win32-cv-1.html
>   vs.
>   https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/WIN32/ThreadWin32.m3?rev=1.210.2.1;content-type=text%2Fplain
>   I wrote this:
>   PROCEDURE XWait(m: Mutex; c: Condition; act: Activation;
>                  alertable: BOOLEAN) RAISES {Alerted} =
>    (* LL = m on entry and exit, but not for the duration
>     * see C:\src\jdk-6u14-ea-src-b05-jrl-23_apr_2009\hotspot\agent\src\os\win32\Monitor.cpp
>     * NOTE that they merge the user lock and the condition lock.
>     * http://www.cs.wustl.edu/~schmidt/win32-cv-1.html
>     *   "3.3. The Generation Count Solution"
>     *)
>
>   Do we have the problems described in README.CV?
>
>   I haven't looked through the ACE code to see
>   to what extent they resemble solution 3.3, or if they
>   changed as a result of this discussion -- which I admit I don't understand
> and haven't read closely.
>
>
> Spurious wakeups are ok, though should be minimized.
>
> I'd still rather not drop pre-Vista support but I realize it becomes more interesting as time advances.
>
>   Thank you,
>    - Jay
>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>

-- 
Rodney Bates
rodney.m.bates at acm.org