aspose file tools*
The moose likes Threads and Synchronization and the fly likes Reentrant vs Thread Safety Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Reentrant vs Thread Safety" Watch "Reentrant vs Thread Safety" New topic
Author

Reentrant vs Thread Safety

Pho Tek
Ranch Hand

Joined: Nov 05, 2000
Posts: 761

I'm trying to get a definitive answer on the difference between Reentrancy and Thread Safety:

As this blog post describes it, Brian Goetz's definition is:

But because intrinsic locks are reentrant, if a thread tries to acquire a lock that it already holds, the request succeeds. Reentrancy means that locks are acquired on a per-thread rather than per-invocation basis.

So reentrancy in Java means that one does not need to reacquire a lock if an embedded code block needs the same lock. This is quite a departure from the functional programming use of the term which relates to Idempotence.

Even the wikipedia entry begs for some rethinking:

Therefore, reentrance is a stronger property than thread-safety and by definition results in it: every reentrant function is thread-safe, but not every thread-safe function is reentrant.

The way I see it reentrancy is a stricter form of the Law of demeter i.e. you can only play with toys (objects) pass into your methods. And even then, we need to qualify that play also means not mutating those object parameters.

I don't agree with the statements that Every threadsafe function is reentrant. A thread safe function in java can as a side effect mutate state. But reentrancy does not allow side effects; you can only return state changes by representing the side effects as return values.
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

Pho: I don't agree with the statements that Every threadsafe function is reentrant.

True, that is what the wiki entry also says rite? Every threadsafe function is *not* reentrant. However, in java, every threadsafe function indeed is reentrant because lock are taken on per thread basis(as Brian Goetz said) and so a thread acquiring a lock can re-enter in the function without worrying about how many threads are waiting for the lock.

Pho: A thread safe function in java can as a side effect mutate state.

Absolutely, infact a function is thread safe because it can mutate state without leaving the data in an inconsistent state in presence of multiple threads trying to execute the same code.
Pho:But reentrancy does not allow side effects

Why do you say so? I can change a global state from inside a reentrant function. isnt?

Reentrancy and thread-safety are two different behvaiors of any program however in java thread-safe programs can be reentrant without doing anything extra. In general, every reentrant function is threadsafe until and unless it behaves differently for different threads i.e. it does something like "if thread name is x then do this else do that, when thread x already has already entered once.". The reason being, if you have wrote a reentrant function then it means the function is prepared for more than one concurrent execution.
[ January 27, 2008: Message edited by: Nitesh Kant ]

apigee, a better way to API!
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
There seems to be an assumption in this thread that "reentrant" is a term restricted to the topic of threading. It isn't.

Java locks are reentrant. That means that a thread that already holds the lock can safely enter another block of code, synchronised using the same lock. Some other platforms do not have reentrant locks, and you somehow have to ensure you don't try to lock something you already locked (it's horrid).

But one can talk about reentrancy in other terms. For instance, even in a single-threaded program, one can have reentrant and non-reentrant methods. A reentrant method would be one that can safely be entered, even when the same method is in progress, further up the call stack (of the same thread). A non-reentrant method would not be safe to use in that way.

An example of a non-reentrant method would be one whose task is to write some text to a file. If that method were reentered, one would likely end up with a garbled mixture of two different bits of text. This sort of thing can happen in logging infrastructure, for instance.


Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Reentrant vs Thread Safety