Subj : Re: reliability of setting thread priority
To   : comp.programming.threads
From : gottlobfrege
Date : Fri Feb 25 2005 06:47 am


Alexander Terekhov wrote:
> gottlobfrege@gmail.com wrote:
> [...]
> > I could wait and call CreateMutex() during the first usage, but
then
> > I'm back to needing a flag/exchange to protect that,
>
> No, you don't need anything to "protect that".
>
> >                                                      and it starts
to
> > seem no better than what I already have.
>
> CreateMutex() with subsequent locking is done on first usage by all
> threads as long as the initialization is not complete. That's why the

> mutex is named.

No, I understand that part about a named mutex.  I was talking about
storing for later use.  But I see the real difference here...

>
[... a bunch of code in Alex's language :-) ... ]
>

Basically, if I understand everything correctly, what I take away as
most important is that you have minimized the use of the named mutex to
be needed ONLY in the case of a contention, whereas I was going to be
using it more/all the time.  Obviously your way makes more sense. It is
cliche, but "why didn't I think of that?"

hmmm,....  so you have 'replaced' the mutex with a auto_reset_event.  I
remember wanting to use an event to wake the waiting threads, but
didn't put it all together - I like how the first thread in doesn't
need to create the event - just check to see if there is one needing
fired on unlock().

By the way...
>
> #define SWAP_BASED_MUTEX_FOR_WINDOWS_INITIALIZER { 0, 0 }
>

why do we need things like this (and PTHREAD_ONCE_INIT, etc)?  I
thought the language ensured that global statics were initialized to 0?
 I do remember a beta DEC Alpha compiler that didn't do this, but I
thought that was just a bug.  Are these macros necessary or
defensive/paranoia?

Thanks,
Tony.

.