Subj : Re: Memory Barriers, Compiler Optimizations, etc.
To   : comp.programming.threads
From : SenderX
Date : Sun Feb 06 2005 09:46 pm

> So if you explain your issues in a way I can understand.
> Clearly stating what you think is an issue I could send
> details to the appropriate people and try and effect
> change if I agree.

Here are some questions that need clarification in your documentation:

1. Can external data depend on the return value from a failed CAS?

2. Does WaitFor_xxx_Object(s) API's have acquire semantics?

3. How about ReleaseSemaphore? Does that have release semantics?



4:

static volatile int a = 0, b = 0;


a = 1;
b = 2;
ReleaseSemaphore( sema, ... );

AnotherThread
------------------
WaitForSingleObject( sema, ... );
if ( a + b != 3 ) { abort(); }


Does this example work with the memory visibility model that Microsoft
semaphores conform to?



Humm...   ;)



Add this to your documentation:

ReleaseSemaphore
--------------------

A release barrier is executed before the semaphore increment. This means
that all preceding loads and stores will be visible before the increment.


ReleaseSemaphore - WaitFor_xxx API
--------------------

An acquire barrier is executed after the semaphore decrement. This means
that the decrement will be visible before any subsequent loads and stores.


I wonder if Alex would approve of this type of documentation...

:O

.