Re: SpinLock/Mutex : Difference ?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

CRITICAL_SECTION is VERY fast when there is no contention.
IF ther is a contention, it gives you _limited_ busy spin wait, and then, if
it doesn't work out, you have to go to kernel anyway.

"Hugo gleaves@xxxxxxxxxxx>" <hugh<underbar> wrote in message
news:D3ADE2F2-4CC9-474A-BCCF-DD560849C259@xxxxxxxxxxxxxxxx
Man, what a story, I have to say I've seen that kind of thing too. In my
view
anyone who suggests anything like that has no appreciation of the
engineering
nor any professional maturity.

However, I have to ask how is that fool's suggestion "pretty much the same
idea as in this thread"?

I am totally opposed to the kind of thing he was suggesting.

All I said is that user-mode code sometimes has a real need for a very
fast
locking mechanism, I never once said that user mode code should in any way
access or use or interfere with kernel mode mechanisms, I would never
suggest
such a thing.

But it is naive to believe that non-kernel mode developers never need very
fast read/write locks.

Even the OS kernel does not support read/write spinlocks, but would it not
be good if it did? Surely there are scenarios within driver design where a
read spinlock would be useful?

Hugo


"Pavel A." wrote:

For working in huge companies like that, pure technical merits too often
are not enough to stay in. Need to have strong "communication skills"
in order to sell your idea. Good luck.
--pa


"tanix" <tanix@xxxxxxxxx> wrote in message
news:hggafe$ot7$2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
In article <OFiPAJ$fKHA.1112@xxxxxxxxxxxxxxxxxxxx>, "Alexander
Grigoriev"
<alegr@xxxxxxxxxxxxx> wrote:
By definition, spinlock is a busy loop. It only makes sense to do if
the
spinlock owner is guaranteed to never get preempted by another thread.
In
kernel mode, this is done by setting IRQL to DISPATCH_LEVEL. In user
mode,
this is not possible.

Good point.

Actually, when I was doing a contract with Intel on a multi-gigabit
network card, there was one guy that was suggesting to do something
totally out of the wall in my view. Pretty much the same idea as in
this thread.

They were trying to squeze out as much performance as possible.
So, this "smart", fat blob, came up with the idea to manipulate
the kernel level synchronization objects from the app level, such
as resetting the count of kernel level semaphores under some
contitions.

On a weekly project meeting I told him: you will never prove this
thing is going to work. That is the whole point with semaphores.
They have been mathematically proven to work. Once you start resetting
the counts at will, outside of the normal semaphore mechanics,
you'll be fixing this thing for years to come.

The result?

They fired me. Not him.
I wonder if they were ever able to make that network card to work.

When they gave me this project to create a hack to manipulate the
kernel level structures from the user mode, and gave me a couple
of weeks to do that, I could not believe these smart donkeys.

It takes YEARS to work on things like these. These are some of
the central concepts in O/S design and the very idea of separation
of kernel and user mode. I nearly flipped out when manager told
me my "project".

Some people really need their brains examined.
Where did they get their estimates on "improving performance"
by slaughtering some of the most fundamental concepts in o/s
design and architecture just escapes me.

CRITICAL_SECTION provide an option of limited spinning in case of
contention, if you expect that the CS will mostly be held for very
short
time.


"Hugo gleaves@xxxxxxxxxxx>" <hugh<underbar> wrote in message
news:574400EE-AFAF-4620-BDDD-7E49608392E0@xxxxxxxxxxxxxxxx
The idea of a spinlock is to ensure secure access/updates to some
datum,
usually for operations that are very very brief. So although some
other
thread/process may have to "spin" for a time, the time is deemed to
brief
as
to be not a serious performance issue.

The kind of operations that might be suited to a spinlock protection
are:

1) Updating several fields atomically in some shared structure.
2) Adding/removing an entry from a shared list.

As Don says a Mutex is much more sophisticated and expensive and
although
very uself in Win32 programming is no match for a spinlock when it
comes
to
raw speed (this is why device drivers use them).

The real question here is why has MS not provided developers with a
spinlock
API for user mode code?

I had to hand craft such a beast in C, it has to support:

1) Nested locking (a spinlock can be acquired 'n' times and must then
be
released 'n' times).
2) Read/Write locking modes.
3) Not end up dragging its heels because of these needs.

If you do a lot of work with shared/mapped memory as we do, then such
an
API
is very important, if you rely on Mutexes it will cost dearly, also
the
interlock functions alone wont let you easily do the above (but they
do
provide the foundation).

I've been interested for some time in seeing open source or public
domain
implementations of a user-mode spinlock API (one that is truly tested
on
multicore H/W) but there seems to be absolutely nothing, what we have
seems
to be pretty good but it is pretty complex and I worry sometimes...

;)


"o0Zz" wrote:

Thank you very much !

"Daniel Terhell" <daniel@xxxxxxxxxxxxxxxx> a ecrit dans le message
de
groupe
de discussion : emRp7$LdKHA.2188@xxxxxxxxxxxxxxxxxxxxxxx
"m" <m@xxx> wrote in message
news:eP9kilIdKHA.6096@xxxxxxxxxxxxxxxxxxxxxxx
The loop will consume all 100% of a single CPU until the lock is
acquired, the thread is interrupted by a higher priority thread
or
the
thread quantum ends (and the OS schedules another thread).


That information is incorrect, on Windows a spinlock raises to
DISPATCH_LEVEL (or higher) so it is not possible to get
interrupted
by
any
thread. It's not even possible for the thread to finish its
quantum
while
it spins or for the dispatcher to schedule another thread on the
same
CPU.
It can get interrupted by an ISR but it will return (to the
spinning
state) as soon as the ISR has executed and returns control.

//Daniel


.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.



.

Relevant Pages

  • Re: SpinLock/Mutex : Difference ?
    ... You seem to think that a spinlock is is something that only the kernel can ... But anyone can write an equivalent API for user mode, all you need to do is ...
    (microsoft.public.win32.programmer.kernel)
  • Re: SpinLock/Mutex : Difference ?
    ... I never once said that user mode code should in any way ... Even the OS kernel does not support read/write spinlocks, ... spinlock owner is guaranteed to never get preempted by another thread. ... as resetting the count of kernel level semaphores under some contitions. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: SpinLock/Mutex : Difference ?
    ... you have to go to kernel anyway. ... I never once said that user mode code should in any way ... spinlock owner is guaranteed to never get preempted by another thread. ... the kernel level synchronization objects from the app level, ...
    (microsoft.public.win32.programmer.kernel)
  • Re: SpinLock/Mutex : Difference ?
    ... The kind of operations that might be suited to a spinlock protection are: ... API for user mode code? ... MS recommends to hold a spin lock for no more than 50 microsecs ... If you do a lot of work with shared/mapped memory as we do, then such an API ...
    (microsoft.public.win32.programmer.kernel)
  • Re: SpinLock/Mutex : Difference ?
    ... kernel mode, this is done by setting IRQL to DISPATCH_LEVEL. ... as resetting the count of kernel level semaphores under some contitions. ... kernel level structures from the user mode, ... The kind of operations that might be suited to a spinlock protection are: ...
    (microsoft.public.win32.programmer.kernel)