Re: Thread question [off-topic]

Mihai Osian <zzz@xxxxxxx> writes:

Dear Paul,

I am glad that you learned the following:
a) a mutex *is* necessary, even for 32 bit data

Learned when? I learned when mutex is necessary, and when it's not
necessary, oh, about 15 years ago ...

b) "volatile" is a lightweight alternative (*see final note)

You persist in your mistakes even when experts tell you it's a
mistake. Oh well, I give up.

Check my modified program.

Your modified program has a bug in it: it calls
pthread_mutex_{un}lock 10000 times more often then necessary.

You might as well compare a loop with lock/unlock against an empty
loop. Of course the empty loop will be faster.

The mutex locking is implemented as follows ...
As you see, there are a lot of operations there,

Nobody argues with that.

much more than a direct memory access.

Or that.

IMHO the above function will _always_ take more
time than the assignement of an int, even one that's stored in the
main memory instead of a register.

Or this. However, see below.

But you can't write correct or reliable or efficient multi-threaded
programs using volatile, and your insistence that using volatile
is somehow better borders on (to put it politely) foolishness.

The results of my own benchmark with the extended loop:

Are invalid because of your bug. Here are my results with the bug:

$ gcc -O2 -pthread volatile2.c -DDOSYNC && time ./a.out
....
real 0m18.905s
user 0m37.801s
sys 0m0.006s

$ gcc -O2 -pthread volatile2.c -DVOLATILE=volatile && time ./a.out
....
real 0m0.515s
user 0m0.702s
sys 0m0.002s

So far consistent with your results -- using locking is much worse.

And now with the bug fixed:

$ gcc -O2 -pthread volatile2.c -DDOSYNC && time ./a.out
....
real 0m0.260s
user 0m0.438s
sys 0m0.004s

QED.

I'll leave it as an exercise for you to find your performance bug.

*Final note: Just for the record: I do not advise anyone to use
volatiles instead of mutexes, because the C standard says no word
about "volatile" making a variable thread-safe. Actually, the C
standard does not mention threads at all (AFAIK). So, my "official"
position is: use volatiles for performance, but _only_ if you know
what you are doing.

What you don't seem to realize is that without understanding memory
architecture, bus cache coherence protocol(s), read and write
memory barriers, memory consistency models, and a whole host of
other non-trivial topics, you *never* know what you are doing
(with volatile), and even if you do understand all of the above,
and the answer comes to down to volatile; that answer is correct
only on that *one* specific (class of) machine.

If you wish to understand more, please read this excellent book:
http://www.amazon.com/UNIXR-Systems-Modern-Architectures-Multiprocessing/dp/0201633388

Once you've read the chapters explaining what hardware must do
preserve *illusion* of consistent memory in a multiprocessor system,
I am sure you'll abandon the notion that "simple assignment to an
int in main memory" is actually simple (and perhaps will also abandon
the notion that you "know what's going on" when you use volatile).

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
.

Relevant Pages

  • Re: Should I use mutex in this context?
    ... My main thread asks the worker thread to terminate if system is ... memory system, the result of the write may be indefinitely delayed from the ... mutex; using a mutex would be the recommended approach. ... or you can cheat and declare the bool volatile. ...
    (microsoft.public.vc.language)
  • Re: Is the following code MT-Safe?
    ... First, you're not protecting any ... This variable will be destroyed and the mutex[*] released when the scope ... >going back to main memory to get the new value which was set by the ... If all access to _bRunning is protected by a mutex, then volatile serves no ...
    (microsoft.public.vc.mfc)
  • Re: [PATCH] input: xpad.c - Xbox 360 wireless and sysfs support
    ... cleanup function for the ktype and free the memory. ... made that submissions while holding a mutex should be GFP_ATOMIC. ... It is true while holding a spinlock, not a mutex. ... Please post that BUG. ...
    (Linux-Kernel)
  • Re: [PATCH 1/3] [BFIN] Blackfin architecture patch for 2.6.18
    ... indicates bad locking or bad memory barriers, etc., somewhere. ... This is not a bug. ... defined as volatile, becasue the hardware may change it without ... After all memory mapped register are not so different of mmio on standard ...
    (Linux-Kernel)
  • Re: When is "volatile" used instead of "lock" ?
    ... to get the address of a stack variable to a background thread. ... I'm suggesting that the memory model ... lock pattern works without making the instance member volatile; ... fields shared amongst more than one thread despite following the locking ...
    (microsoft.public.dotnet.languages.csharp)
Loading