|
|
Post by amitk3553 on May 3, 2013 5:13:07 GMT
Hello all,
What is the basic difference betwwen mutex and seamaphore?
If seamaphore is one step more beneficial than mutex, then where is the advantage of mutex??
Regards
Amit kumar
|
|
|
|
Post by gchopra on May 3, 2013 5:48:04 GMT
Hello all, What is the basic difference betwwen mutex and seamaphore? If seamaphore is one step more beneficial than mutex, then where is the advantage of mutex?? Regards Amit kumar Hello Amit, 1.) Both are used to synchronize accesses to shared resources. 2.) Mutex is for a single shared resource while semaphore is more general, used for multiple shared resources. |
|
|
|
Post by amitk3553 on May 3, 2013 6:08:42 GMT
Hello all, What is the basic difference betwwen mutex and seamaphore? If seamaphore is one step more beneficial than mutex, then where is the advantage of mutex?? Regards Amit kumar Hello Amit, 1.) Both are used to synchronize accesses to shared resources. 2.) Mutex is for a single shared resource while semaphore is more general, used for multiple shared resources. Hello gagan, Its(seamaphore) for multiple shared resource(resource is single but shared) not for resources
Infact both mutex and seamaphore have one shared resource and multiple owners....but in case of seamaphore, there is one advantage that after serving one owner an event is generated(which tells that resource is unlocked), so any other owner can lock
whereas in mutex no such event is generated and all owners send continuously requests to lock the mutex.
So my question is that wheres the advantage of mutex?Due to events generation feature in seamaphore, its more synchronizable than mutex.
Regards
Amit Kumar
|
|
|
|
Post by gaganpreet on May 7, 2013 6:04:07 GMT
Hello Amit, 1.) Both are used to synchronize accesses to shared resources. 2.) Mutex is for a single shared resource while semaphore is more general, used for multiple shared resources. Hello gagan, Its(seamaphore) for multiple shared resource(resource is single but shared) not for resources
Infact both mutex and seamaphore have one shared resource and multiple owners....but in case of seamaphore, there is one advantage that after serving one owner an event is generated(which tells that resource is unlocked), so any other owner can lock
whereas in mutex no such event is generated and all owners send continuously requests to lock the mutex.
So my question is that wheres the advantage of mutex?Due to events generation feature in seamaphore, its more synchronizable than mutex.
Regards
Amit Kumar
Hello Amit, To explain the difference between the two let me illustrate these with an example. Let us consider we have a 4KB buffer as resource and there are n number of threads who can use this buffer. Using Mutex:It provides mutual exclusion which means at one time only one thread can have the access that 4 KB buffer to perform different operations on it. In short, a mutex is a locking mechanism which means only one thread can have the access to the shared resource at one time. Using Semaphores:It is a more generalized mutex. It means that if we have 4 KB buffer then we can split this 4 KB buffer into four 1 KB buffers to make identical resources and a semaphore can be associated with these four buffers. Then four threads can access these four 1 KB buffers simultaneously and can perform their function. There is always a maximum value associated with semaphores i.e. count (in this case it is 4(no of identical resources)). So, semaphores are known as counting semaphores. Whenever a thread occupies a resource semaphore count is decreased and whenever a thread releases a resource, it is signaled and semaphore count is increased. When the semaphore count reaches 0 the thread is queued and have to wait until the resource gets freed. Apart from mutex and counting semaphore, we have binary semaphore which have only two states associated with it i.e. "taken" and "not taken". Binary semaphores have no ownership attribute and can be released by any thread or interrupt handler regardless of who performed the last take operation. Because of this binary semaphores are often used to synchronize threads with external events implemented as ISRs, for example waiting for a packet from a network or waiting that a button is pressed. Now, Here is a question: How binary semaphore is different from mutex?Answer is that in case of mutex, if thread A locks a resource then only that thread can have the access to release that resource, but in case of binary semaphore situation is different as: If thread A locks a resource that any other thread B can accidentally release(signal) it. As I have explained above that semaphore has an ISR associated with it but in case of mutex there is no ISR associated. Apart from this binary semaphores are used for mutual exclusion and synchronization. Basically, we prefer mutex while implementing mutual exclusion and binary semaphores are preferred for implementing synchronization(between threads or between threads and ISR) |
|
|
|
Post by amitk3553 on May 7, 2013 7:19:30 GMT
Hello gagan, Its(seamaphore) for multiple shared resource(resource is single but shared) not for resources
Infact both mutex and seamaphore have one shared resource and multiple owners....but in case of seamaphore, there is one advantage that after serving one owner an event is generated(which tells that resource is unlocked), so any other owner can lock
whereas in mutex no such event is generated and all owners send continuously requests to lock the mutex.
So my question is that wheres the advantage of mutex?Due to events generation feature in seamaphore, its more synchronizable than mutex.
Regards
Amit Kumar
Hello Amit, To explain the difference between the two let me illustrate these with an example. Let us consider we have a 4KB buffer as resource and there are n number of threads who can use this buffer. Using Mutex:It provides mutual exclusion which means at one time only one thread can have the access that 4 KB buffer to perform different operations on it. In short, a mutex is a locking mechanism which means only one thread can have the access to the shared resource at one time. Using Semaphores:It is a more generalized mutex. It means that if we have 4 KB buffer then we can split this 4 KB buffer into four 1 KB buffers to make identical resources and a semaphore can be associated with these four buffers. Then four threads can access these four 1 KB buffers simultaneously and can perform their function. There is always a maximum value associated with semaphores i.e. count (in this case it is 4(no of identical resources)). So, semaphores are known as counting semaphores. Whenever a thread occupies a resource semaphore count is decreased and whenever a thread releases a resource, it is signaled and semaphore count is increased. When the semaphore count reaches 0 the thread is queued and have to wait until the resource gets freed. Apart from mutex and counting semaphore, we have binary semaphore which have only two states associated with it i.e. "taken" and "not taken". Binary semaphores have no ownership attribute and can be released by any thread or interrupt handler regardless of who performed the last take operation. Because of this binary semaphores are often used to synchronize threads with external events implemented as ISRs, for example waiting for a packet from a network or waiting that a button is pressed. Now, Here is a question: How binary semaphore is different from mutex?Answer is that in case of mutex, if thread A locks a resource then only that thread can have the access to release that resource, but in case of binary semaphore situation is different as: If thread A locks a resource that any other thread B can accidentally release(signal) it. As I have explained above that semaphore has an ISR associated with it but in case of mutex there is no ISR associated. Apart from this binary semaphores are used for mutual exclusion and synchronization. Basically, we prefer mutex while implementing mutual exclusion and binary semaphores are preferred for implementing synchronization(between threads or between threads and ISR) Hello gaganp, In mutex, when one thread had locked the buffer, then at that time, are the other threads also trying to lock buffer or in the meantime they are idle and will start trying to lock buffer after previous lock is released?? How their(threads) priority would be determined??Means at a time, no. of threads trying to lock buffer then which one would be successful in locking the buffer??Who will decide this thing as ISR is determinig in seamaphore?? |
|
|
|
Post by gaganpreet on May 7, 2013 8:18:17 GMT
Hello Amit, To explain the difference between the two let me illustrate these with an example. Let us consider we have a 4KB buffer as resource and there are n number of threads who can use this buffer. Using Mutex:It provides mutual exclusion which means at one time only one thread can have the access that 4 KB buffer to perform different operations on it. In short, a mutex is a locking mechanism which means only one thread can have the access to the shared resource at one time. Using Semaphores:It is a more generalized mutex. It means that if we have 4 KB buffer then we can split this 4 KB buffer into four 1 KB buffers to make identical resources and a semaphore can be associated with these four buffers. Then four threads can access these four 1 KB buffers simultaneously and can perform their function. There is always a maximum value associated with semaphores i.e. count (in this case it is 4(no of identical resources)). So, semaphores are known as counting semaphores. Whenever a thread occupies a resource semaphore count is decreased and whenever a thread releases a resource, it is signaled and semaphore count is increased. When the semaphore count reaches 0 the thread is queued and have to wait until the resource gets freed. Apart from mutex and counting semaphore, we have binary semaphore which have only two states associated with it i.e. "taken" and "not taken". Binary semaphores have no ownership attribute and can be released by any thread or interrupt handler regardless of who performed the last take operation. Because of this binary semaphores are often used to synchronize threads with external events implemented as ISRs, for example waiting for a packet from a network or waiting that a button is pressed. Now, Here is a question: How binary semaphore is different from mutex?Answer is that in case of mutex, if thread A locks a resource then only that thread can have the access to release that resource, but in case of binary semaphore situation is different as: If thread A locks a resource that any other thread B can accidentally release(signal) it. As I have explained above that semaphore has an ISR associated with it but in case of mutex there is no ISR associated. Apart from this binary semaphores are used for mutual exclusion and synchronization. Basically, we prefer mutex while implementing mutual exclusion and binary semaphores are preferred for implementing synchronization(between threads or between threads and ISR) Hello gaganp, In mutex, when one thread had locked the buffer, then at that time, are the other threads also trying to lock buffer or in the meantime they are idle and will start trying to lock buffer after previous lock is released?? How their(threads) priority would be determined??Means at a time, no. of threads trying to lock buffer then which one would be successful in locking the buffer??Who will decide this thing as ISR is determinig in seamaphore?? Hello Amit, Basically, there are two operations associated with mutex depending upon which the locking and unlocking of resources is done. These are "lock" and "unlock". What happens in lock state is that whenever a thread enters the process and it tries to lock the already locked resource then the incoming thread has to wait until the thread is unlocked and is queued. And in unlock state, thread relinquishes its ownership from the resource and the threads waiting in the queue for that resource gets the ownership of the thread. Now whenever there are multiple threads in the queue which are waiting for the resource to get unlocked, then the thread having the highest priority gets the ownership of the resource. But if two threads have the same priority then which thread gets the ownership depends upon the scheduling algorithm. Basically used scheduling algorithm is FIFO(First In First Out) i.e. the thread which entered the queue first will get the ownership. Regards, Gaganpreet |
|
|
|
Post by amitk3553 on May 10, 2013 9:25:19 GMT
Hello gaganp, In mutex, when one thread had locked the buffer, then at that time, are the other threads also trying to lock buffer or in the meantime they are idle and will start trying to lock buffer after previous lock is released?? How their(threads) priority would be determined??Means at a time, no. of threads trying to lock buffer then which one would be successful in locking the buffer??Who will decide this thing as ISR is determinig in seamaphore?? Hello Amit, Basically, there are two operations associated with mutex depending upon which the locking and unlocking of resources is done. These are "lock" and "unlock". What happens in lock state is that whenever a thread enters the process and it tries to lock the already locked resource then the incoming thread has to wait until the thread is unlocked and is queued. And in unlock state, thread relinquishes its ownership from the resource and the threads waiting in the queue for that resource gets the ownership of the thread. Now whenever there are multiple threads in the queue which are waiting for the resource to get unlocked, then the thread having the highest priority gets the ownership of the resource. But if two threads have the same priority then which thread gets the ownership depends upon the scheduling algorithm. Basically used scheduling algorithm is FIFO(First In First Out) i.e. the thread which entered the queue first will get the ownership. Regards, Gaganpreet Hello all, I found one thing about priority mechanisms.All mechanisms of scheduling that we had discussed here are used in embedded systems in softaware. But in SystemC we use following procedure for priority and scheduling which is based on events: 1) a process runs and catches 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 Regards Amit |
|
