Critical sections and Semaphores

[Rigel]

Alright silly question. Why is there a distinction between critical sections and semaphores? Isn't a critical section a semaphore with a resource count and maximum resource count of 1? Why didn't the designers just implement a semaphore so it is defaulted as a "critical section"?

[wildfrog]

Reentrant vs. Non-reentrant

A thread can enter the same critical section (over and over again) without blocking itself. If you do that with a semaphore the "count" will eventually bocome 0, and the thread will block (and possibly deadlock).

- petter

[Rigel]

I did a little more research and came across another possible reason.
Perhaps this is due to the fact that semaphores can synchronize threads across multiple processes while critical sections cannot.

[wildfrog]

Yup, that is another good reason.

- petter

[Andreas Masur]

Critical sections are usually faster than semaphores since the operating system does not need to switch to kernel mode for them. This will reduce the number of CPU cycles drastically. Drawback of this is the lack of using them over process boundaries...

[Andreas Masur]

Reentrant vs. Non-reentrant

A thread can enter the same critical section (over and over again) without blocking itself. If you do that with a semaphore the "count" will eventually bocome 0, and the thread will block (and possibly deadlock).

Are you sure about that? In my eyes, this shouldn't make any difference... :confused:

[wildfrog]

Are you sure about that? In my eyes, this shouldn't make any difference...

Well, by reading this...

MSDN on Semaphores:

A thread that waits repeatedly for the same semaphore object, however, decrements the semaphore's count each time a wait operation is completed; the thread is blocked when the count gets to zero.


MSDN on Critical Sections:

After a thread has ownership of a critical section, it can make additional calls to EnterCriticalSection or TryEnterCriticalSection without blocking its execution. This prevents a thread from deadlocking itself while waiting for a critical section that it already owns.

...i get that impression.

- petter

[Andreas Masur]

Cool...didn't know that...well...one more reason why I don't use semaphores... ;)

Thanks...

[kirants]

Interesting.. as far back as I can think, don't remember having used semaphores at all :)

[wildfrog]

Interesting.. as far back as I can think, don't remember having used semaphores at all... and you're OK with that?!

I've found them usefull on a couple of occasions...maybe just about 3 times the last 15 years, but still usefull. I believe one time was an attempt to write an interprocess RW lock.

- petter

[kirants]

... and you're OK with that?!
Oh yes.. superfine :p :p :p :p

Maybe I haven't come across a situation to apply a semaphore till date. And I am bad at conjuring up a situation to see how it works.. Summary.. I am lethargic ;)

[MrViggy]

Well, if you don't need to sync across processes, why use a semaphore! Simple critical sections are good enough.

;)

Viggy

[Andreas Masur]

Well, if you don't need to sync across processes, why use a semaphore! Simple critical sections are good enough.

well...and for syncing across processes, you can use a mutex...so...why bother with semaphores... :p

[kirants]

well...and for syncing across processes, you can use a mutex...so...why bother with semaphores... :p
Well, but mutexes allow access to 1 user at a time.. Semaphores, on the other hand, allow upto n users.

[wildfrog]

Another nice feature is that any thread, not just the holding ones, can release a semaphore (increase the semaphore count)...

- petter

[MrViggy]

Well, but mutexes allow access to 1 user at a time.. Semaphores, on the other hand, allow upto n users.
D'OH! I wasn't thinking!

You are correct, and come to think of it, I've never used semaphores either!

Viggy

[Rigel]

Ok... I'm convinced that I'm probably not going encounter a situation where I will have to use semaphores anytime soon. :o

[Axter]

semaphores are good to use when you want to limit code that has the potential to over run your resources.
For example, if you had code that had to create a thread each time an event occurred, you might want to make sure it never creates too many threads, or your application could crash.
You can easily limit the number of threads created at one time by using a semaphore.