-
October 18th, 2008, 08:45 AM
#1
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
-
October 18th, 2008, 11:48 AM
#2
Re: User-mode semaphore possible?
The critical section is the only user mode synchronization object available on Windows - all the rest are kernel mode objects (mutex, semaphore, etc.).
-
October 21st, 2008, 02:38 PM
#3
Re: User-mode semaphore possible?
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.
-
October 21st, 2008, 03:15 PM
#4
Re: User-mode semaphore possible?
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.
-
October 23rd, 2008, 01:34 PM
#5
Re: User-mode semaphore possible?
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).
-
October 23rd, 2008, 03:37 PM
#6
Re: User-mode semaphore possible?
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.
-
October 31st, 2013, 08:50 AM
#7
Re: User-mode semaphore possible?
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.
-
November 10th, 2013, 10:46 AM
#8
Re: User-mode semaphore possible?
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 ?
-
October 31st, 2013, 10:41 AM
#9
Re: User-mode semaphore possible?
Just wanted to mention that unnamed kernel objects can work cross-process as well using DuplicateHandle.
-
November 4th, 2013, 08:47 AM
#10
Re: User-mode semaphore possible?
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.
-
November 4th, 2013, 11:21 AM
#11
Re: User-mode semaphore possible?
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.
-
November 12th, 2013, 08:53 AM
#12
Re: User-mode semaphore possible?
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.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|