pthread_cond_t vs pthread_mutex_t
Jason Mancini
locking and unlocking 3 mutexes. The results are
4.2 million mutex lock-unlocks per second. Doing the same
for two threads that wait and signal each other results
in 26,000 wait-signals per second using conditional
variables.
Any explanations as to why conds are so much slower
than mutexes? There are no collisions in any of the
mutex acquisitions. Also it seems like the mutex rate
should be higher that it is.
Is there anything faster available for putting many
threads to sleep and waking them up many times a
second?
Thanks, Jason
Steve Watt
Jason Mancini <jman...@pa.dec.com.gofigure> wrote:
[ uncontested mutex lock/unlock pairs go at 4.2 million per second ]
[ using condition variables in the middle goes 26,000 per second ]
>Any explanations as to why conds are so much slower
>than mutexes?
Because they always cause the calling thread to block, which can have
substantial overhead. You didn't mention what OS/platform this is,
but that can be an expensive function.
>There are no collisions in any of the
>mutex acquisitions. Also it seems like the mutex rate
>should be higher that it is.
In your condition variables code, there is most likely some collision in
mutex acquisition, if you are using the condition variables as intended,
i.e. with a controlling mutex.
>Is there anything faster available for putting many
>threads to sleep and waking them up many times a
>second?
Not in any portable fashion.
What's the problem you're really trying to solve? Seems that making
threads sleep/wake a lot isn't, in itself, a useful goal.
--
Steve Watt KD6GGD PP-ASEL-IA Packet: KD6GGD @ N0ARY.#NOCAL.CA.USA.NA
ICBM: 121W 56' 58.1" / 37N 20' 14.2" Internet: steve @ Watt.COM
Free time? There's no such thing. It just comes in varying prices...
Dave Butenhof
> I wrote a small program that loops many times,
> locking and unlocking 3 mutexes. The results are
> 4.2 million mutex lock-unlocks per second. Doing the same
> for two threads that wait and signal each other results
> in 26,000 wait-signals per second using conditional
> variables.
Of course, this information is largely useless without knowing what
hardware and software you're using. But nevermind that -- it probably
doesn't matter right now that the numbers are meaningless.
> Any explanations as to why conds are so much slower
> than mutexes? There are no collisions in any of the
> mutex acquisitions. Also it seems like the mutex rate
> should be higher that it is.
So, you're trying to compare the performance of UNCONTENDED (that is,
non-blocking) mutex lock/unlock versus condition variable waits. Note
that waiting on a condition variable requires a mutex lock and an
unlock, PLUS the wait on a condition variable. Waking a thread that's
waiting on a condition variable also requires locking and unlocking the
same mutex (in order to reliably set the predicate that must be tested
for a proper condition wait). (If you're not locking in the signalling
thread, then you're doing it wrong and your measurements have no
relevance to a real program.)
Why, exactly, would you expect the performance of the condition variable
protocol to be equivalent to the mutex protocol that consists of a small
part of the condition variable protocol -- and, most importantly, that
excludes the actual BLOCKING part of the condition variable protocol?
As for the mutex rate -- 4.2 million per second means that each
lock/unlock pair takes less than 1/4 of a microsecond. Given the
inherent memory system costs of instructions intended to allow
synchronization on a multiprocessor, you'd need to be running on a
REALLY fast machine for that number to be "bad".
> Is there anything faster available for putting many
> threads to sleep and waking them up many times a
> second?
If your 26,000 per second rate isn't good enough, then the answer is
"probably not". Still, by my count, that's way up in the range of "many
times a second". What exactly are you attempting to accomplish by all
this blocking and unblocking, anyway? If you're doing it as a
consequence of some real work, then what's important is the performance
of the WORK, not the cost of individual operations involved in the work.
(You should really be trying to AVOID blocking, not worrying about
blocking faster, because blocking will always be slower than not
blocking.)
Synchronization is not the goal of multithreaded programming. It's a
necessary evil, that's required to make concurrent programming work.
Synchronization is pure overhead, to be carefully minimized. Every
program will run faster without synchronization... unfortunately, most
concurrent programs won't run CORRECTLY without it.
/---------------------------[ Dave Butenhof ]--------------------------\
| Compaq Computer Corporation bute...@zko.dec.com |
| 110 Spit Brook Rd ZKO2-3/Q18 http://members.aol.com/drbutenhof |
| Nashua NH 03062-2698 http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----------------[ Better Living Through Concurrency ]----------------/
gauravlnm...@gmail.com
> I wrote a small program that loops many times,
> locking and unlocking 3 mutexes. The results are
> 4.2 million mutex lock-unlocks per second. Doing the same
> for two threads that wait and signal each other results
> in 26,000 wait-signals per second using conditional
> variables.
>
> than mutexes? There are no collisions in any of the
> mutex acquisitions. Also it seems like the mutex rate
> should be higher that it is.
>
> threads to sleep and waking them up many times a
> second?
>
yeah