Semaphore Vs Mutex

Semaphores use a counter that counts how many tasks are waiting, a mutex is just a binary value. Semaphores can be used to organise queues while a mutex is grabbed by the first task that gets there.

Peter

You could perhaps say that a mutex behaves like a semaphore with a count of 1.

The count is equal to the number of tasks that can share the resource protected by the semaphore.

I would say semaphores are more for synchronisation where as mutex are for resource protection.But mutex can be used for synch also but due to their timing impacts,we prefer semaphores over mutex for synch!

Regards, s.subbarayan

A semaphore is a general-purpose inter-task communication primitive. A mutex (MUTual EXclusion) is a special-purpose inter-task communication primitive whose purpose is to limit access to a resource to a single task at any given time.

A semaphore can be used to implement synchronization, event notification, or even as a mutex.

More accurately, a semaphore whose count is 1 can be used as a mutex.

However, I've used mutitasking kernels with special purpose mutexes with special features. For example, if a task attempts to free a resource it does not own, the attempt will fail, or if a task acquires a resource it already owns, it will succeed, but it must free the resource a second time (nested acquisition). A simple semaphore by itself cannot provide these features.

This has always seemed a bogus example to me. I've never run across a resource that could be shared by, e.g., two tasks, but not three. Either the resource is limited to a single task, or has no limitations in that regard at all.

But I admit I haven't seen everything yet...

Regards,

-=Dave

....

Hmm, disk drives/file systems and networks spring to mind, they may or may not use semaphores, but maximum number of open files per task/whole system, and on networks the maximum number of connections is not 1 or infinite. Some network devices/systems support 1 connection others a specific value related to the system/device and its capabilities usually total RAM, max buffers or task memory size limited.

There may be other reasons as well (e.g. speed of processing or I/O bottlenecks), however there may well be a none arbitrary or non-infinite number of tasks that can share a resource.

... snip ...

For example, you have three modems on telephone lines. A process wants a modem, so it simply opens the 'modem' file. If all three are in use, the open fails, else it grabs one. As far as the 'modem' device file is concerned there is only one such.

I would add network printers in this example which also requires a counting semaphore! Regards, s.subbarayan

As described, you couldn't implement your "modem open" function using a simple counting semaphore: If all the modems are in use, the open wouldn't fail, it would simply wait until one _was_ available. Which may or may not be the desired behavior.

And you'd still need a mutex to determine which modem was available and allocate it.

Off the top of my head, if I were implementing a modem pool I'd probably just use a resource structure with a mutex, along with a set of synchronization primitives (e.g., binary semaphores initialized to zero) to allow tasks to wait for freed modems (the resource structure would have a queue of waiting tasks). The calling function would be able to specify the behavior if no modem were available (fail or wait with optional timeout).

Regards,

-=Dave