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

"Uenal Mutlu" wrote
> "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.

See also this DOC of Micro$oft:
http://www.microsoft.com/whdc/driver/kernel/locks.mspx
(http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/Locks.doc)

.