Subj : Re: Challenge: Multithreading & Synchronization To : comp.programming.threads From : doug Date : Mon May 23 2005 05:47 pm "David Butenhof" wrote in message news:Pdlke.5874$ms2.3633@news.cpqcorp.net... > Giancarlo Niccolai wrote: >> doug wrote: >> >> >>>Actually, I have a (hopefully) quick question. Is the above algorithm >>>safe in a system where you dynamically create the recursive mutex? >> >> Theoretically yes, but then the problem is NOT in the mutex, but in your >> app, trying to access a non initialized mutex when it is still not >> available. > > To put it another way that might make this more clear... > > A mutex is SHARED DATA. Normally, mutexes are initialized statically, or > at initialization time before threads are created, and people don't think > about the implications of "mutex visibility". However when you initialize > mutexes dynamically you need to concern yourself with the memory > visibility rules just as with any other dynamic shared data. > > If you have reliable visibility to the mutex, then you'll have no trouble > reading the initialized data; including the owner field with (one > presumes) an initial value correctly communicating to each possible thread > that it is not the current owner. But if you do not have reliable > visibility, then you have much worse problems than not seeing the initial > owner value... all use of that mutex is completely indeterminate. (For > example, the first attempt to lock from another thread might misread the > LOCK status, and attempt to block on an uninitialized wait queue...) cool, that's what I thought. Ta guys. (The scenario I wrote out above does seem impossible to me [as you say, how do you get to this 'new CB' in the first place safely?] Was wanting to make sure I understood the more general visibilty stuff.) > > -- > Dave Butenhof, David.Butenhof@hp.com > HP Utility Pricing software, POSIX thread consultant > Manageability Solutions Lab (MSL), Hewlett-Packard Company > 110 Spit Brook Road, ZK2/3-Q18, Nashua, NH 03062 .