wood burning stoves 2.0*
The moose likes Threads and Synchronization and the fly likes Non-reentrant lock Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Non-reentrant lock" Watch "Non-reentrant lock" New topic
Author

Non-reentrant lock

Rahul Mahindrakar
Ranch Hand

Joined: Jul 28, 2000
Posts: 1851
a mutex is defined as a simple non-reentrant mutual exclusion lock. what is meant by a non-reentrant lock??
Suneel Setlur
Ranch Hand

Joined: Nov 26, 2000
Posts: 202
A Mutex is a concept relating to mutual exclusion locks
Mutual exclusion locks (mutexes) prevent multiple threads from simultaneously executing critical sections of code which access shared data (that is, mutexes are used to serialize the execution of threads). All mutexes must be global. A successful call to acquire a mutex will cause another thread that is also trying to lock the same mutex to block until the owner thread unlocks the mutex.
Mutexes can synchronize threads within the same process or in other processes. Mutexes can be used to synchronize threads between processes if the mutexes are allocated in writable memory and shared among the cooperating processes and have been initialized for this task.

------------------
Suneel
[This message has been edited by Suneel Setlur (edited February 01, 2001).]


Suneel
Rahul Mahindrakar
Ranch Hand

Joined: Jul 28, 2000
Posts: 1851
Suneel ,
I was looking for a definition for "non-reentrant".
Thanks anyhow
Jim Baiter
Ranch Hand

Joined: Jan 05, 2001
Posts: 532
Reentrant locks allow a thread to reacquire the lock. This
prevents the thread from deadlocking itself. Of course, along
with everything else there is a price for this so if there is
no possibility of the thread trying to reacquire the lock, the
non-reentrant Mutex is ok.
Rahul Mahindrakar
Ranch Hand

Joined: Jul 28, 2000
Posts: 1851
In single-threaded processes there is only one flow of control. The code executed by these processes thus need not to be reentrant or thread-safe. In multi-threaded programs, the same functions and the same resources may be accessed concurrently by several flows of control. To protect resource integrity, code written for multi-threaded programs must be reentrant and thread-safe.
Reentrance and thread-safety are both related to the way functions handle resources. Reentrance and thread-safety are separate concepts: a function can be either reentrant, thread-safe, both, or neither.
A reentrant function does not hold static data over successive calls, nor does it return a pointer to static data. All data is provided by the caller of the function. A reentrant function must not call non-reentrant functions.
A non-reentrant function can often, but not always, be identified by its external interface and its usage.
A thread-safe function protects shared resources from concurrent access by locks. Thread-safety concerns only the implementation of a function and does not affect its external interface.
I found this here
[This message has been edited by Rahul Mahindrakar (edited February 05, 2001).]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Non-reentrant lock