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

Alexander Terekhov wrote:
> gottlobfrege@gmail.com wrote:
> [...] BTW, I had a
> copy&paste error in the previous posts. First check needs msync::acq.

you were also missing a semi-colon a few lines later, but I wasn't
going to say anything :-).

> But you can get rid of a mutex and use DCCI variation instead.
> [...]
>
> The only problem is that Win95/i386 doesn't have CAS for that
> attempt_update() with original IBM style bool interface above.
>

InterlockedCompareExchange() doesn't work?  Because of the loop inside
of it or aba concerns or what?

> [...]
> > why do we need things like this (and PTHREAD_ONCE_INIT, etc)?  I
> > thought the language ensured that global statics were initialized
to 0?
>
> Yes, but other implementations may need something nonzero or even
some
> nonportable implementation specific "magic" that gets hidden by
macros.
>

I understand that in theory, but I also can't imagine a case where 0s
wouldn't work.  For pthread_once, it is just a 2-state flag - I can't
imagine how 0 can't work as one of the states.
For your stuff, you have a flag and a pointer, and what the 3 values of
the flag are is arbitrary, as long as they are unique.  Again 0 seems
good enough (if not better than most).

If the 'magic' needs to be more than just setting some constant values
(ie needs function calls), then I think we are in trouble - at least
for my intented usage - again, I don't want to rely on the order of
static initializers.

Of course, I've been around long enough to know that some platforms are
stranger than fiction, so my 'from experience' side of my brain says
the macros make sense, but my math/logic side says that it is not
possible for 0 not to be a good enough value for the needs.

Does anyone know cases where 0 doesn't work? (for PTHREAD_ONCE_INIT or
similar)?


> regards,
> alexander.

Thanks,
Tony.

.