There's been a lot of discussion of this general issue as part of PR#
65776 (although I don't recall if anyone brought up re-ordering).

http://community.qnx.com/sf/discussion/do/listPosts/projects.core_os/discussion.osrev.topc6394

My opinion is that _Mtxinit() should include a barrier if any is
required.

On Thu, 2009-03-05 at 15:39 -0500, Oleh Derevenko wrote:
> I was just reviewing commit log for libc for fun and noticed the following thing.
> 
> -----------------------------------------
> -			_Mtxinit(&str->_Flock);
> -
> +			_Mtxinit(&_Mtx);
> +			str->_Flock = _Mtx;
> -----------------------------------------
> The comment says:
> PR:63915
> CI:cburgess
> CI:dbailey
> CI:bstecher
> CI:acripps
> 
> For statically allocated streams (stdio, stderr, stdout etc), multiple
> threads are  trying to call fprintf at the same time, and one thread is
> attempting to initialise the stream mutex (in InitLocks, there is a
> potential window for a race condition, where a second thread may
> perform the test for the existence of
> the lock, and go on to use it before the first thread has
> initialised the mutex completely. This could leave the mutex in an
> inconsitent state and even locked
> by an owner well after the thread has completed the fprintf operation.
> 
> This solution is to ensure that the the stream lock is assigned to the
> stream only after initialisation of the mutex has completed.
> 
> 
> So my question is: for multiprocessor system where writes can be re-ordered, is not initialization of mutex into a 
local varaible and its assignment to a shared variable potentially as dangerous as initialization in place? What if 
writes will be reordered and for some other thread value in shared varaible still appears before mutex is completely 
initialized? Should not memory barrier be used here to separate these two operations?
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post23707
> 

No, it doesn't need a barrier instruction. The mutex isn't in the _Mtx
variable, it's in the memory pointed to by the variable. 

On Thu, Mar 05, 2009 at 03:39:38PM -0500, Oleh Derevenko wrote:
> I was just reviewing commit log for libc for fun and noticed the following thing.
> 
> -----------------------------------------
> -			_Mtxinit(&str->_Flock);
> -
> +			_Mtxinit(&_Mtx);
> +			str->_Flock = _Mtx;
> -----------------------------------------
> The comment says:
> PR:63915
> CI:cburgess
> CI:dbailey
> CI:bstecher
> CI:acripps
> 
> For statically allocated streams (stdio, stderr, stdout etc), multiple
> threads are  trying to call fprintf at the same time, and one thread is
> attempting to initialise the stream mutex (in InitLocks, there is a
> potential window for a race condition, where a second thread may
> perform the test for the existence of
> the lock, and go on to use it before the first thread has
> initialised the mutex completely. This could leave the mutex in an
> inconsitent state and even locked
> by an owner well after the thread has completed the fprintf operation.
> 
> This solution is to ensure that the the stream lock is assigned to the
> stream only after initialisation of the mutex has completed.
> 
> 
> So my question is: for multiprocessor system where writes can be re-ordered, is not initialization of mutex into a 
local varaible and its assignment to a shared variable potentially as dangerous as initialization in place? What if 
writes will be reordered and for some other thread value in shared varaible still appears before mutex is completely 
initialized? Should not memory barrier be used here to separate these two operations?
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post23707
> 

-- 
Brian Stecher (bstecher@qnx.com)        QNX Software Systems
phone: +1 (613) 591-0931 (voice)        175 Terence Matthews Cr.
       +1 (613) 591-3579 (fax)          Kanata, Ontario, Canada K2M 1W8