Re: mutex overkill ?

Tech-Archive recommends: Speed Up your PC by fixing your registry

creation is not CPU intensive,but acquisition can be expensive from a perf
perspective (not necessarily cpu usage, but rahter the inability to maximize
the CPU). a mutex (or event or semaphore) acquisition will require a UM->KM
transition. a critical section will not make this transition if there is no
contention. a critical section is only useful in one process while a
mutex/semaphore/event may be shared across multiple processes (and have
different rules for ownership)

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"stef" <stef.pellegrino@xxxxxxxxx> wrote in message
news:1158418581.311732.205420@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hello,

I would like to know if the creation of a mutex is very CPU time
consuming or not, or "just a little bit"...

I've searching for that on the web, but it's not very clear.




thanx



.

Relevant Pages

  • Re: mutex overkill ?
    ... For any given acquisition, a critical section is usually, but not always, ... section is *ALWAYS" faster, compared to event or mutex, and this is not ... Please do not send e-mail directly to this alias. ... the CPU). ...
    (microsoft.public.win32.programmer.kernel)
  • Re: mutex overkill ?
    ... in this case that the acquisition must be symmetric. ... significantly improve the probability of entering the CS without the call to ... It is understandable that if thread A has to spin N times before ... the owner of the section has more CPU time available, ...
    (microsoft.public.win32.programmer.kernel)
  • Re: race on multi-processor solaris
    ... Let's say I am OS providing the mutex ... >little hardware contention, but lots of software contention (ie lots ... I'm not sure I'd call that "lots of cycles"; ... thread doesn't use CPU; so CPU cycles are available to do ...
    (comp.unix.solaris)
  • Re: race on multi-processor solaris
    ... >> locks will suffer some of the same CPU wastage as the lock free version. ... There is a difference -- adaptive mutexes spin with non-atomic operations, ... > should cause the mutex to adapt and block. ...
    (comp.unix.solaris)
  • Re: lazy pthread_cond_timedwait (linux)
    ... takes several seconds to several *minutes* delay after abstime to ... even though it had plenty of opportunities to lock the mutex. ... CPU and one process per node, ...
    (comp.programming.threads)