InitializeCriticalSectionAndSpinCount
Andy Cooper
InitializeCriticalSectionAndSpinCount function in the
Win32 platform SDK. There is a note in the MSDN library
which reads
Windows 2000/XP: If the high-order bit is set, the
function preallocates the event used by the
EnterCriticalSection function. Do not set this bit if you
are creating a large number of critical section objects,
because it will consume a significant amount of nonpaged
pool.
My first question is how do I set the high order bit?? I
assume that if I & the value I wish to use with
2147483648, that this will set the highest bit to one, but
won't this also make the spin count quite large?? Does
the function ignore the high word of the DWORD??
My second question is how can I tell if a thread actually
entered the critical section via the spin count or via the
event object? It would seem helpful to have this
information in order to tune the value of the spin count.
Thanks in advance for any assistance
Andy Cooper
David Lowndes
>assume that if I & the value I wish to use with
>2147483648, that this will set the highest bit to one
Don't AND it, OR it!
>, but
>won't this also make the spin count quite large?? Does
>the function ignore the high word of the DWORD??
Presumably it does!
>My second question is how can I tell if a thread actually
>entered the critical section via the spin count or via the
>event object?
I don't know how you'd ascertain that.
Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq
My address is altered to discourage junk mail.
Please post responses to the newsgroup thread,
there's no need for follow-up email copies.
William DePalo [MVP]
news:574001c1949e$58d4cfd0$36ef2ecf@tkmsftngxa12...
> My question(s) are regarding the
> InitializeCriticalSectionAndSpinCount function in the
> Win32 platform SDK. There is a note in the MSDN library
> which reads
> My first question is how do I set the high order bit??
dwCount = dwCount | 0x80000000;
Regards,
Will
Slava M. Usov
news:574001c1949e$58d4cfd0$36ef2ecf@tkmsftngxa12...
[...]
> My second question is how can I tell if a thread actually
> entered the critical section via the spin count or via the
> event object? It would seem helpful to have this
> information in order to tune the value of the spin count.
As has already been suggested, you can emulate the critical section API with
your own routines that will log that information. Alternatively, you might
use, say, GetSystemTimeAsFileTime() before and after EnterCriticalSection():
if the thread has to wait on the event object, then it will most likely
yield the rest of the time slice and probably a few following slices, so the
values returned by GetSystemTimeAsFileTime() will be different, while for
the spinning case they will be the same. Additionally, you might use the
Pentium RDTSC instruction, to obtain the exact number of CPU clock times
EnterCriticalSection() has consumed.
S
Neill Clift [MS]
to solve a somewhat thorny problem. Critcal sections in
contention create the events on demand. If the event
creates fail (lack of available memory etc) then these
API's would raise exceptions (both the Enter and Leave
functions). Starting in Windows XP we no longer raise
exceptions in the out of memory cases (For Enter and
Leave, Initialize still does) and so applications wanting
to be robust in this environment don't have to set this
bit. The critical section code falls back to a global
object in reduced memory situations (when event allocation
fails). For Windows XP this bit is ignored as a result.
Neill.
>.
>
Daniel Lohmann
<nei...@microsoft.com> wrote:
>The idea behind setting the upper bit of the spin count is
>to solve a somewhat thorny problem. Critcal sections in
>contention create the events on demand. If the event
>creates fail (lack of available memory etc) then these
>API's would raise exceptions (both the Enter and Leave
>functions). Starting in Windows XP we no longer raise
>exceptions in the out of memory cases (For Enter and
>Leave, Initialize still does) and so applications wanting
>to be robust in this environment don't have to set this
>bit. The critical section code falls back to a global
>object in reduced memory situations (when event allocation
>fails). For Windows XP this bit is ignored as a result.
>Neill.
However, this has also the drawback of getting things still more
indetermined. I used the upper bit mostly not because I'm afraid of
exceptions, but to know that I have an upper limit of time used to
perform the EnterCriticalSection() call by not having to create the
event object in EnterCriticalSeciton(). And if it could happen in XP
that there is silently used a single global object, this is getting
even worse :-(
(I know that NT is not a hard realtime system. However, it is
behaving quite well in soft realtime tasks, especially on SMP
systems.)
Daniel
Neill Clift [MS]
impossible to handle exceptions generated by
EnterCriticalSection and LeaveCriticalSection because
they left the CS in a state you couldn't recover from.
This forced apps that wanted to be robust into using
preallocation. We really want all apps to be robust so
removing the raise was my top priority. I was left with a large
number of internal apps using this flag and the associated memory
usage did have an effect on the memory footprint. I therefore decided
to ignore this flag. My reasoning is that any app getting the global
object is getting it because its under memory pressure. Performance
will be poor in this case anyway. I want to be robust in preference to
performance in this out of memory case. I chose to ignore the flag
because it helps a great deal with memory footprint. There is of course
a one time penalty when we allocate the event but its not a great deal
of time in comparison to waiting anyway. I don't really believe the
difference between just waiting and allocating an event and waiting is
significant.
Neill.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Daniel Lohmann" <dan...@uni-koblenz.de> wrote in message
news:8ato3uo3uav0k3ksi...@4ax.com...
Daniel Lohmann
<nei...@microsoft.com> wrote:
> [...]
>My reasoning is that any app getting the global
>object is getting it because its under memory pressure. Performance
>will be poor in this case anyway. I want to be robust in preference to
>performance in this out of memory case. [...]
Okay, I see this. That's also the reason why I was not that afraid of
exceptions. If an exception is thrown because of low memory, there
would be some really big problems - and any kind of timing is
obsolete then.
>There is of course
>a one time penalty when we allocate the event but its not a great deal
>of time in comparison to waiting anyway. I don't really believe the
>difference between just waiting and allocating an event and waiting is
>significant.
Could you quantify this a bit? How long does it take to create an
event object compared to the pure waiting overhead (waiting for an
object that is already singaled or gets signaled in the same moment)?
I know that it is not possible to give us exact timings, but a kind of
estimation like
waiting + creating < 2 * waiting (usually!)
would be nice.
Daniel
Neill Clift [MS]
say just the call overhead for a wait. You can time these things yourself
if you want numbers. What I am getting at here is that there is contention
on the lock so you are about to wait. Its not the actual wait mechanics
that going to take time but the context swaps and the wait itself.
Neill.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Daniel Lohmann" <dan...@uni-koblenz.de> wrote in message
news:64br3uglsfs70hdrh...@4ax.com...