• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 720
  • Last Modified:

Threads,mutex,condition variable,semaphore?

1)I have read that threads are multiple points of
  execution within a process.O.K
  My understanding is that different functions could
  be executed as threads concurrently within a process's
  context.But what does concurrent mean here?Obviously
  there is no context switching here,so how is concurrency

  What is a mutex,condition variable&semaphore?
  If all of them are synch. primitives what's there
  difference & when is each used.

  Kindly reply ASAP.
  Thank you.

  • 2
1 Solution
Actually, there is context switching between threads.  Yes, they do share the same address space for the heap and program text, but they have their own private stack, and some implementations still do MMU map changes to deal with this more effectively.  Even if the system you're on doesn't do this, you still need to change some context (like register values and program counter).  This is often called "lightweight context switching," as threads are sometimes called "lightweight processes."

As for the second half of your question, the following are taken from Tannenbaum's _Modern_Operating_Systems_:

  "In [Dijkstra's] proposal, a new variable type, called a semaphore was introduced.  A semaphore could have the value 0, indicating that no wakeups were saved, or some positive value if one ore more wakeups were pending.
  Dijkstra proposed having two operations, DOWN and UP (generalizations of SLEEP and WAKEUP, respectively).  The DOWN operation on a semaphore checks to see if the value is greater than 0.  If so, it decrements the value (i.e., uses up one stored wakeup) and just continues.  If the value is 0, the process is put to sleep.  Checking the value, changing it, and possibly going to sleep is all done as a single, indivisible atomic action.  It is guaranteed that once a semaphore operation has started, no other process can access the semaphore until the operation has completed or blocked.  This atomicity is absolutely essential to solving synchronization problems and avoiding race conditions.
 The UP operation increments the value of the semaphore adressed.  If one or more processes were sleeping on that semaphonre, unable to complete an earlier DOWN operation, one of them is chosen by the system (e.g., at random), and is allowed to complete its DOWN.  Thus, after an UP on a semaphore with processes sleeping on it, the semaphore will still be 0, but there will be one fewer process sleeping on it.  The operation of incrementing the semaphore and waking up one process is also indivisible.  No process ever blocks doing an UP.
  Critical regions are most easily implemented using semaphonres, monitors, and similar constructions.  One technique that is commonly used in threads packages is the mutex, which is a kind of watered-down semaphonre.  A mutex is always in one of two states, unlocked or locked.  Two operations are defined on mutexes.  The first one, LOCK, attempts to lock the mutex.  If the mutex is unlocked, the LOCK succeeds and the mutex becomes locked in a single atomic action.  If two threads ttry to lock the same mutex at exactly the same instant, an event that is only possible on a multiprocessor, on which different threads run on different CPU's, one of them wins and the other loses.  A thread that attempts to lock a mutex that is already locked, such as the loser above, is blocked.
  The UNLOCK operation unlocks a mutex.  If one or more threads are waiting on the mutex, exactly one of them is released.  The rest continue to wait.
  Mutexes are like binary semaphonres (i.e., semaphores that my only have the values 0 or 1).  They are not like counting semaphores.  Limiting them in this way makes them easier to implement.
  Another synchronization feature that is sometimes available in thread packages is the condition variable, which is similar to the condition variable used for synchronization in monitors.  Each condition variable is normally associated with a mutex at the time it is created.  The difference between mutexes and condition variables is that mutexes are used for short term locking, mostly for guarding the entry to critical regions.  Condition variables are used for long-term waiting until a resource becomes available.
  The following situation occurs all the time.  A thread locks a mutex to gain entry to a critical region.  Once inside the critical region, it examines system tables and discovers that some resouce it needs is busy.  If it simply locks a second mutex (associated with the resource), the outer mutex will remain locked and the thread holding the resource will not be able to enter the critical region to free it.  Deadlock results.  Unlocking the outer mutex lets other threads into the critical region, causing chaos.
  One solution is to use condition variables to acquire the resource, as shown in Fig 12-5(a).  Here waiting on the condition variable is defined to automatically perform the wait and unlock the mutex atomicly.  Later when the thread holding the resource frees it, as shown in Fig. 12-5(b),.it calls wakeup, which is defined to either wakeup exactly one thread, or all the threads waiting on the specific condition variable....
    lock mutex;
    mark resource as busy;
    unlock mutex;

    lock mutex;
      mark resource as free;
    unlock mutex;
arutAuthor Commented:
Thanks Chris, for your effort.
You're welcome.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now