Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x
?
Solved

Threads,mutex,condition variable,semaphore?

Posted on 1999-07-07
3
Medium Priority
?
711 Views
Last Modified: 2008-02-20
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
  acheived.

  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.

 
0
Comment
Question by:arut
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
3 Comments
 
LVL 14

Accepted Solution

by:
chris_calabrese earned 300 total points
ID: 2011378
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....
  12.5(a)
    lock mutex;
    while(resource_busy)
      wait(condition_variable);
    mark resource as busy;
    unlock mutex;

  12.5(b)
    lock mutex;
      mark resource as free;
    unlock mutex;
    wakeup(condition_variable);
0
 

Author Comment

by:arut
ID: 2011379
Thanks Chris, for your effort.
0
 
LVL 14

Expert Comment

by:chris_calabrese
ID: 2011380
You're welcome.
0

Featured Post

[Webinar] Lessons on Recovering from Petya

Skyport is working hard to help customers recover from recent attacks, like the Petya worm. This work has brought to light some important lessons. New malware attacks like this can take down your entire environment. Learn from others mistakes on how to prevent Petya like worms.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

A metadevice consists of one or more devices (slices). It can be expanded by adding slices. Then, it can be grown to fill a larger space while the file system is in use. However, not all UNIX file systems (UFS) can be expanded this way. The conca…
Using libpcap/Jpcap to capture and send packets on Solaris version (10/11) Library used: 1.      Libpcap (http://www.tcpdump.org) Version 1.2 2.      Jpcap(http://netresearch.ics.uci.edu/kfujii/Jpcap/doc/index.html) Version 0.6 Prerequisite: 1.      GCC …
Learn how to get help with Linux/Unix bash shell commands. Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…
Learn how to navigate the file tree with the shell. Use pwd to print the current working directory: Use ls to list a directory's contents: Use cd to change to a new directory: Use wildcards instead of typing out long directory names: Use ../ to move…
Suggested Courses

721 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question