User-mode semaphore possible?

Hello

In win32, I believe the following is true. EnterCriticalSection() and LeaveCriticalSection() can be used to synchronize threads without requiring expensive system calls that transition into kernel-mode when there is no contention on the lock object. They do this by using a specific test-and-set instruction on the CPU. When there is contention on the lock, blocked threads will wait on a kernel object and are not awakened until the lock is released.

I believe a semamphore is a more fundamental synchronization object and would like to know if it is possible to make one that does not require entering kernel-mode when there is no contention. That is, can it be made if you have access to TestAndSet() and any waitable kernel objects, such as events and semaphores? (I'm fairly sure Enter/LeaveCriticalSection() can be emulated from these.)

Eagerly awaiting responses...

Thanks

The critical section is the only user mode synchronization object available on Windows - all the rest are kernel mode objects (mutex, semaphore, etc.).

Thanks Arjay, I wasn't positive that the critical section was the only user-mode synchronization method available in Windows.

The main question, though, is it is possible to create a user-mode semaphore (ie object and related functions) with, for example, the Win32 functions

InterlockedCompareExchange(),
Create/ReleaseSemphore(),
Create/SetEventand(),
WaitForSingleObject(), etc?

Perhaps it is impossible and this is why such an synchronization object is not provided.

I believe the difference of synchronization objects between user mode and kernel mode is whether they can work across processes. The kernel mode mutex, event, and semaphore can all work across process whereas the user mode critical section cannot.

I would expect that you could make a user mode semaphore; however, like a critical section, it would only be for in-process use.

Ahah, yes I see how to do it. See below for an implementation of something similar, which (I cannot resist adding) I though of myself just before.

http://msdn.microsoft.com/en-us/magazine/cc163642.aspx

I was struggling to see how to use the test-and-set instruction to do more general operations (eg Interlocked.Increment() in the example).

As Arjay has pointed out, such an implementation will work only within the threads of one single process. It will not work across different processes.

Well, hope following site will help you know more about User-mode semaphore. http://www.tech-archive.net/Archive/.../msg00286.html

Quote:

---

Originally Posted by tossy

Well, hope following site will help you know more about User-mode semaphore. http://www.tech-archive.net/Archive/.../msg00286.html

---

Note there is a distinction about creating an event in user mode and a 'user mode' event that the link refers to. The event is still a kernel object, it just is getting created in user mode as opposed to getting created in kernel mode (like during creation of driver code).

Quote:

---

Originally Posted by MikeAThon

As Arjay has pointed out, such an implementation will work only within the threads of one single process. It will not work across different processes.

---

Add an name (string) attribute to create().
Use that string to created a named shared memory section, to hold the Lock's data in.
Then you can access the lock from multiple processes/cores.

Quote:

---

Originally Posted by Arjay

The critical section is the only user mode synchronization object available on Windows - all the rest are kernel mode objects (mutex, semaphore, etc.).

---

This isn't entirely true anymore since Windows Server 2003.

When a thread is waiting for a critical section and it ends up either reaching it's spin count limit or reaching the end of it's timeslice, the thread is for all intents and purposes suspended.

The thread then won't wake up again and retest the critical section by itself anymore. It's the Kernel that will manage the suspended threads in a wait queue, and when the CS becomes available, the kernel will awaken a thread from the wait queue (not necessarily in FIFO order)and transfer control to it.

This was done to increase overall throughput by prevending lots of threads all continuously polling the same CS. Internally the kernel uses a kernel-semaphore for each CS to achieve this.


So while it's true that the CS is the most lightweight basic synchronisation object, it does not guarantee it won't ever leave user mode. Under the normal assumptions a CS should be used for (very short lived locks) this ends up being an overall win. Fewer kernel transitions, at a slight overhead on user mode.
Abusing a CS under the 'lightweight' assumption for something they aren't really designed for, could end up giving you poorer overal performance.

If for some reason you MUST guarantee absolutely no kernel transition, you will need to make your own lock primitive.

You can make lock primitives of your own by using elementary CPU instructions, or by extention using the Interlocked_XXX family of functions.
The caution here is: Unless you're REALLY sure of what you're doing, you are unlikely to do better than the OS provided synchronisation primitives that have been throuroughly tested and proven in the field.
Only do so when you know what you do and you know what drawbacks you're going to get. Typically while user-mode primitives can sort "faster rotation", as you get more threads synchronising on the same primitive, this could have a negative effect on overal system availability. spin-loops use CPU time in the hopes of an "available soon" condition. If lots of threads do that, you could have all your CPU time going lost on spin-loops.


NAMED synchronisation objects can work accross processes (on the same machine).
UNNAMED synchronisation objects can work only in a single process (and are typically faster than their named counterpart)
CriticalSections are single process only.


Countrary to the above statements. It IS possible to make promitives of your own that will work cross-process. So yes, you can make a cross-process semaphore of your own that works in multiple processes, the trick to this one, is to get a little help from the OS kernel mode to set it up and use a shared memory page to store the semaphore "lock and count information".
Again, unless you really know what you're doing, you're unlikely to get something that works as well as the OS primitives.

Just wanted to mention that unnamed kernel objects can work cross-process as well using DuplicateHandle.

true. I keep forgetting about that.

It just never seems like a "better" approach to named objects for the stuff I typically work on.

It also means you have to have some formal communication between the 2 processes so one process can access the handle of the other to duplicate it, or one process services a "give me a (duplicate) handle to X" request of the other process.

Named objects seem more elegant.

With the duplicate handle approach, there is the chicken and the egg problem (of getting the handle over to the second process so it can be duplicated). I generally prefer using a named object as well.

In fact, that's what I do in my memory mapped file CG article.

C++ Programming: Memory Mapped Files using RAII

...because I know you guys have nothing better to do than read a 3 year old article of mine. ;)

Quote:

---

Originally Posted by OReubens

If for some reason you MUST guarantee absolutely no kernel transition, [...]

---

just for my personal curiosity, in which scenario would this be required ?

Anything where timing is critical, i.e. anything "real time" (in so far as windows can even satisfy that).
Multimedia recording/playback, process control, drivers (although for windows you'd usually want a kernel driver for this case), ...

There's better dedicated OSes for such type of things, but sometimes, people insist on doing such with Windows. :rolleyes: