Re: mutex overkill ?
- From: "m" <m@xxx>
- Date: Mon, 18 Sep 2006 09:37:08 -0400
You are neglecting SMP and spinning in that analysis - although the ultimate
conclusion is correct:
For any given acquisition, a critical section is usually, but not always,
faster.
"anton bassov" <soviet_bloke@xxxxxxxxxxx> wrote in message
news:1158529755.520222.222400@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Doron,
but there is improvement, esp in the case where you can successfully
acquire
the lock w/out a wait. that is still a win.
A small adjustment to your statement is needed - "especially" should be
replaced with
"if and only if".... Otherwise, there is no improvement whatsoever (in
fact, there is even some additional overhead, although it is
negligible)
What my previous post meant to say is that probability of successfull
acquisition may be not so high if section is a "busy place". Therefore,
use of critical section *MAY* improve performance. This clarification
is important, because some people in the NG believe that critical
section is *ALWAYS" faster, compared to event or mutex, and this is not
the case....
Anton Bassov
Doron Holan [MS] wrote:
but there is improvement, esp in the case where you can successfully
acquire
the lock w/out a wait. that is still a win.
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.
"anton bassov" <soviet_bloke@xxxxxxxxxxx> wrote in message
news:1158477321.695637.317730@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Doron,
In fact, critical section is nothing more than event, combined with
locked-increment- and-test - if test fails, the code proceeds to
WaitForSingleObject() on event. Therefore,
the more "contestants" are around and the longer the current "owner"
holds the critical section, the higher the chance of
WaitForSingleObject() call, and, hence, the less significant
performance improvement is, compared to that of system-level
synchronization objects.
Anton Bassov
Doron Holan [MS] wrote:
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
.
- Follow-Ups:
- Re: mutex overkill ?
- From: anton bassov
- Re: mutex overkill ?
- References:
- mutex overkill ?
- From: stef
- Re: mutex overkill ?
- From: Doron Holan [MS]
- Re: mutex overkill ?
- From: anton bassov
- Re: mutex overkill ?
- From: Doron Holan [MS]
- Re: mutex overkill ?
- From: anton bassov
- mutex overkill ?
- Prev by Date: Re: Command line arguments of a remote system process.
- Next by Date: Re: Command line arguments of a remote system process.
- Previous by thread: Re: mutex overkill ?
- Next by thread: Re: mutex overkill ?
- Index(es):
Relevant Pages
|
