Subj : Re: Challenge: Multithreading & Synchronization
To   : comp.programming.threads
From : David Schwartz
Date : Fri May 20 2005 06:47 pm


"Uenal Mutlu" <520001085531-0001@t-online.de> wrote in message 
news:d6lvlm$i3o$05$1@news.t-online.com...

> "David Schwartz" wrote
>>
>> "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)
>>
>>     It is depressing how frequently you prove that you have no idea what
>> you're talking about while you continue to insist that you are right.
>
> So, what exactly do you mean is wrong in my statement above?
> You are just paraphrasing dumb statements without any content.

    You said that the fMyFlag cannot be set unless there is a thread to 
yield to. This is false.

>> Hint: The other thread could be running right now on another CPU, making 
>> it
>> impossible for you to yield to it or switch to it.

> Doesn't matter, in this case it will come back to the same thread on the 
> same CPU.
> What else have you expected will happen?

    Huh? What are you talking about? Do you even understand what I'm saying? 
I'm saying:

    1) You find the lock is locked.

    2) You call SwitchToOtherThread.

    3) Nothing happens because the thread that holds the lock is already 
running on another CPU.

    You just blast by all the hard problems in what you suggest as if they 
didn't exist. And when called on it, you insist that there was, all along, 
some magic somewhere else in your code that makes the problem go away.

> David, it was you who made the following wrong statement:

>> >     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.

    The term is used both ways. You used 'atomic' to refer to naked 
instructions like 'foo++' with foo being an "atmoic type". Again, you fall 
back to behind the scenes magic elsewhere. Well, if I don't point these out, 
how is someone else going to know that for your code to work, they have to 
put tons of magic elsewhere, about which you say *nothing*.

> Which proves it is actually you who has no idea. I mean: how can someone
> claiming knowing these things make such a stupid error? It simply shows 
> you have really > no idea.

    Anyone following this thread can make up there own mind about who knows 
what he's talking about and who doesn't. SMP-safe operations are hugely 
expensive on P4s, and hiding the expense inside unseen magic is bad.

    DS

.