Mutex and semaphore

[amitk3553]

Hello all,

 

What is the difference between mutex and seamaphore?

 

 

 

 

Regards

 

Amit

[David Long]

Hi Amit,

 

A mutex is used to ensure mutual-exclusive access to a shared resource. Think of it as being like having a single key to unlock access to the resource that you pass between processes that request it. Only one process can have it at a time - any other process that wants it will have to wait until the key becomes available.

 

A semaphore is similar but is more like a bucket containing multiple keys. You can set the number of keys in the bucket when it is created, processes request keys just like the mutex and will have to wait ("block") when no key is available. However, unlike the mutex, you can have multiple processes accessing the resource in the same time interval.

 

Regards,

Dave

[amitk3553]

Hello david,

 

Thanks for response.

 

Some more doubts:

 

What is difference between scheduling mechanisms of binary seamaphore and mutex??

 

As i know in binary seamaphore, we use ISR and in mutex we use FIFO for scheduling the priority of threads from which it comes to know that which process would get the access to shared resource??Is this right?

 

 

Regards

Amit Kumar

[David Long]

Hi Amit,

 

I think you are talking about semaphore and mutex in the context of an embedded, multi-threaded software system here. SystemC does not provide all of the features required to model that kind of system (for example there is no built-in scheduler that supports process priorities and pre-emption.

 

The SystemC mutex and semaphore classes run in the evaluation phase and use immediate event notifications so cannot be used to control which process gets access to a shared resource if several are waiting for the mutex/semaphore. sc_mutex and sc_semaphore use the same scheduling mechanism.

 

Regards,

Dave

[amitk3553]

Hi Amit,

 

I think you are talking about semaphore and mutex in the context of an embedded, multi-threaded software system here. SystemC does not provide all of the features required to model that kind of system (for example there is no built-in scheduler that supports process priorities and pre-emption.

 

The SystemC mutex and semaphore classes run in the evaluation phase and use immediate event notifications so cannot be used to control which process gets access to a shared resource if several are waiting for the mutex/semaphore. sc_mutex and sc_semaphore use the same scheduling mechanism.

 

Regards,

Dave

 

Hello Dave,

You said that mutex and seamaphore use the same scheduling mechanism.

 

Please tell something about this mechanism(is this like fifo)??

 

 

 

Regards

Amit

[David Long]

Hi Amit,

 

The scheduling mechanism for sc_mutex and sc_semaphore is very simple and does not have fifo characteristics (i.e. if several processes are waiting for the mutex/semaphore, they are not granted it based on the order in which they requested it - although there is nothing to stop an implementation of SystemC from executing processes in the same order as they are added to the list of runnable processes, the LRM says that the order is implementation defined).

 

The basic operation of a set of processes using a mutex/semaphore could be like this:

 

1) a process runs and grabs the free mutex/semaphore, it then hits a wait before releasing it

2) other processes run and attempt to grab the mutex/semaphore. If it is not free, the processes wait (for an event that is within the mutex/semaphore object)

3) the process with that has grabbed the mutex/semaphore wakes up and frees the mutex/semaphore - this issues an immediate notification on the mutex/semaphore's internal event

4) the processes waiting for the mutex/semaphore get added to the list of runnable processes. One of them starts executing and grabs the mutex/semaphore but hits a wait statement before releasing it

5) the remaining processes in the list of runnable processes will each start executing in the same evaluation phase, but now the mutex/semaphore is locked by the process that started in step 4 so they will block again until the next notifcation of the mutex/semaphore event (as in step 3)

Steps 3 to 4 are repeated until the end of the simulation or until every process has completed its access to the shared resource

 

Hope that is enough to give you the idea!

 

Regards,

Dave

[amitk3553]

thanks Dave