Re: Critical Sections, Thread Priorities, and Pre-emption


"m" <m@xxx> wrote in message news:uyoLvqkbHHA.2552@xxxxxxxxxxxxxxxxxxxxxxx
I would suggest that in the case that you mention, a CS is still better.
If you set the spin count to zero, then you get the same benefit of a Mutex
in cases where there is contention (with a tiny overhead) but in cases
where there is no contention, then you avoid the UM-KM transitions.

True. The tiny overhead in the case of no-contention is a big win over
always transitioning to kernel mode to take an unowned mutex.

There originally was no documented way of intializing the spincount, and
still it is not documented as supported under Win9x -- probably a non-issue
for the OPs case, but which is the basis for my opinions.





There are situations where a Mutex is more desirable then a CS within a
single process, but they usually have more to do with compatibility than
performance. ie extending an existing app, integrating existing apps into
a single app, or working with a broken sync design, that can't easily be
changed, that causes constant contention between many threads.

True.

The other reason to use a Mutex over a CS is to be notified when a thread
abandons the lock.





Of course this is why you must tune the spin count for all critical
sections. This tuning is also hardware dependent so depending on what you
are writing (a desktop app versus an embedded server etc.) the type of
optimizations that are effective will vary. Only the OP can know what is
appropriate to his application.

Yes, dedicated hardware with a known process set is a prime candidate for
such tuning. Software meant to run on end-user computers suffers the
typical "if everyone raised their priority, no one's priority is raised".





BTW: I don't know where the decision to spin or not is implemented, but
since it must be in UM, I doubt that ntoskrnl.exe has anything to do with
it - likely kernel32.dll?

You have a point there. My knowledge must be stale, or incomplete, or more
likely: both. Maybe even just plain wrong!! Habits get born from necessity
and are hard to break. So, I appreciate your corrections to my statements.



.

Relevant Pages

  • adaptive mutexes, was Re: btrfs_tree_lock & trylock
    ... People seem to repeatedly come up with adaptive mutex based on intuitive ... % of time lock is contended ... overhead of entry-exit for lock primitive (spin time) ... if the contention phases are short. ...
    (Linux-Kernel)
  • Re: IOCP critical sections and mutexes
    ... then there is some bug in your ... routines but I recently started some preliminary stress test on a new server ... then pushes it in a queue that will be later processed by my main app ... If I use a mutex instead it works fine. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: IOCP critical sections and mutexes
    ... those are pulled from the queue via GetQueuedCompletionStatus ... BTW, for the record, both the user mode accessible mutex and critical ... My packets never go over 2k in size. ... then pushes it in a queue that will be later processed by my main app ...
    (microsoft.public.win32.programmer.kernel)
  • Re: [PATCH -v4][RFC]: mutex: implement adaptive spinning
    ... Change mutex contention behaviour such that it will sometimes busy wait on ... So far I haven't found any btrfs benchmarks where this is slower than ... Simple spin: dbench reports 560MB/s ...
    (Linux-Kernel)
  • Re: IOCP critical sections and mutexes
    ... mismatch and invalid 'this' pointer). ... instance) and I get pretty much the same crash. ... I mush have done something stupid in my main thread app. ... If I use a mutex instead it works fine. ...
    (microsoft.public.win32.programmer.kernel)
Quantcast