Subj : Re: reliability of setting thread priority
To   : comp.programming.threads
From : gottlobfrege
Date : Fri Feb 25 2005 08:10 pm


Alexander Terekhov wrote:
> gottlobfrege@gmail.com wrote:
> [...]
> > the DCSI.  Would it be possible to start unlocked, and have the
'2nd'
> > one in (ie first contention actually) do the slow_lock, create the
> > event, etc?
>
> Event creation may fail (throw). It is typical to have the "2nd one"
> in some destructor (and 1st one in a constructor of some object where
> it can fail safely). Destructors shall not fail. Fallback to a single

> preallocated global wait/broadcasted beast (so that lock's lazy init
> never fails) in the case of event init failure would mitigate the
> problem, but it isn't really worth the effort (given typical use
> cases). So, it is possible, but brain-dead. MS critical sections work
> that way. ;-)
>
> regards,
> alexander.

For a general lock where you expect lots of contention, the one time
expense of the mutex followed by lots of fast atomic locking later
makes sense.

When expecting little to no contention (for example, serializing
initialization - after the init there is no longer contention, just a
check to see that the init flag is already set) then the possibility of
actually never needing the mutex is intriguing.

Tony.

.