19e2
Subj : Re: Challenge: Multithreading & Synchronization
To   : comp.programming.threads
From : Uenal Mutlu
Date : Sat May 21 2005 04:39 am

"David Schwartz" wrote
>
> "Uenal Mutlu" wrote in message
>
> > "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.

Hae? I've never said such. See above.
The code is intended for multiple threads, not single thread.
You have jumped into the middle of a discussion without first
reading the recent postings in the thread.

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

I don't know of what lock you are talking. Because it is not a mutex, it's just
a condition variable.

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

David, go and make a break, drink a cup of tea or whatever you like, then
read the previous postings more carefully.
Because what you write makes no sense.

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

IMO the only point we are differing is my preference for recursive mutex vs your preference
of non-recursive mutex plus my preference for object locks vs. your application wide
locks (or some call it "thread locking"). So what? Just accept the fact that we differ in our views.

> SMP-safe operations are hugely
> expensive on P4s, and hiding the expense inside unseen magic is bad.

So what's your proposed workaround? Let me guess: the mighty MFENCE, right?
Why don't you think that the InterlockedXXX func already could make use of
it on CPUs which have it?
And, is this statement anyhow related to the original question?

Here is another example of your such totally unrelated and IMO wrong answer:
(this is from the other thread):

>"David Schwartz" wrote
>>
>> "David Holmes" wrote
>>
>> > "David Schwartz" wrote in message
>>
>> >>     I'm afraid that's not true. A typical recursive unlock will need one
>> >> interlocked operation to figure out whether it has to wake other threads
>> > or
>> >> not followed by waking the threads if necessary.
>> >
>> > Why would a *recursive* unlock need to wake anyone?
>>
>>     As I said, assuming it's the last unlock.
>
> Wake not necessary at all (at least in my implementations of both
> recursive and non-recursive mutex methods).

You then replied:

########
    You can always trade-off expenses in one place by moving them to
someplace else. That's why I don't make the argument that recursive mutexes
are bad because they're more expensive than non-recursive mutexes.

    They are in fact more expensive in every implementation I've ever seen
that didn't just deliberately impose the expense on non-recursive mutexes as
well. You can't avoid the fact that an 'Unlock' has to determine whether or
not it's actually going to release the mutex as an additional expense not
present in a non-recursive mutex. You can only remove that expense by making
'Lock' much more expensive so that it can handle the case where it failed to
get the lock but still blocked other threads.

    If you think I'm wrong, prove it. Present an implementation of a
recursive mutex such that it can't be made significantly less expensive by
making it non-recursive. I'll even ignore the overhead of the extra
locks/unlocks, I'm only concerned with the cost of the first lock and the
first unlock. If you can do it, I will call you a genius.

    That said, it really doesn't matter. The problem with recursive mutexes
is not that they hurt performance, because that's generally negligible. It's
that they hide serious design flaws and promote sloppy design. Their *only*
use is to allow you to write code that manipulates an object without knowing
whether or not it holds a lock on that object. And that is just bad, bad,
bad.

    DS
#######

So, see yourself how you answered the question. Your statement
about "wake other threads" is simply wrong, and you have missed to
answer the exact questions people had asked you. Instead you wrote
the above totally unrelated garbage.

.

0