Subj : Re: Challenge: Multithreading & Synchronization
To   : comp.programming.threads
From : Uenal Mutlu
Date : Sat May 21 2005 02:22 am

"David Schwartz" wrote
>
> "Uenal Mutlu" wrote in message
>
> > It depends on the situation.
> > In a time-critical application I usually do the following:
> >  while (!fMyFlag)
> >     MyYield();    // gives up the rest of the time slice, ie.
> > SwitchToOtherThread
> >  //...
>
>     And if there is no other thread?

You don't know what's inside in my MyYield().
And: if there is no other thread then fMyFlag hardly can be set.
FYI/Hint: I don't use Sleep(0)

> > in a non time critical situation I mostly do use something like that:
> >  while (!fMyFlag)
> >     MySleep(100);    // sleeps 100 ms
> >  //...
>
>     Hard to imagine a mutex in a non-time critical situation. Why
> deliberately write bad code?

Sorry, I don't understand. The code above has not necessarily something
todo with mutex use at all. It is just a condition variable lookup from inside
application code.

> > As said, in the examples above the variable fMyFlag is an atomic type,
> > because
> > it is accessed by at least 2 threads.
>
>     The use of an atomic type is insufficient. For platform-specific code,
> memory barriers or interlocked operations must be used. For portable code,
> mutexes must be used.

You don't know how my atomic counter class actually is implemented.
And you also seem to have overlooked what I wrote in my prev posting:
"I personally do use an atomic flag (actually it is an atomic counter with the
possible values 0 and 1). I've this implemented in a class. Internally it uses
InterLockedXXX funcs of the Win32 API."

>     Atomic operations are atomic with respect to a single processor only,
> that is, code cannot be interrupted or signalled during the operation. They
> have no special SMP or multi-threading semantics.

I don't agree. If you use the InterLockedXXX then all this is handled automatically by them.

.