0

I gone through the article "http://www.ibm.com/developerworks/java/library/j-jtp10264/".They mentioned that "The Lock framework is a compatible replacement for synchronisation". I understood that by using Reentrant locks we can hold the lock across the methods, wait for the lock for certain period of time (It is not possible using synchronised block (or) methods). My doubt is, is it possible to replace the application with synchronisation mechanism with Reentrant locks?

For example, I want to implement a thread safe stack data structure, where all the push, pop, getTop methods are synchronised, so in multi threaded environment, only one thread can able to access one synchronised method at a time (If one thread is using push method, no other threads can able to access push, pop, getTop (or) any other synchronised methods of Stack class). Is it possible to implement same thread safe stack data structure using Reentrant lock? If possible, please provide an example to understand this.

Aditya W
  • 652
  • 8
  • 20
Hari Krishna
  • 3,658
  • 1
  • 36
  • 57
  • 2
    There are many alternatives to `synchronized` statements since Java 5, not only `Lock`s. In your case you probably want to leverage the synchronized collections in the `java.util.concurrent` package, instead of re-inventing the wheel. – Mena Oct 10 '16 at 14:52
  • Ya.. I know about concurrent collection, but my question is, is it possible to implement complete Thread safe data structure using lock framework. – Hari Krishna Oct 10 '16 at 14:54
  • The one thing you can't do with `Lock`s but you can with `synchronized` is abuse it through pooled objects. Probably not a bad thing overall. – biziclop Oct 10 '16 at 15:13

4 Answers4

3

Anything you can do with synchronized you can also do with ReentrantLock but not vice-versa. That being said, if all you need are lock/unlock semantics I would suggest synchronized as it's, in my opinion, more readable.

John Vint
  • 39,695
  • 7
  • 78
  • 108
2

The answer is "Yes".

lock - unlock pair used instead of synchronize( ) { ... }. await and signal in Condition is replacement for wait and notify.

talex
  • 17,973
  • 3
  • 29
  • 66
0

Brian Goetz discusses this in "Java Concurrency in Practice" in chapter 13.4:

ReentrantLock is an advanced tool for situations where intrinsic locking is not practical. Use it if you need its advanced features: timed, polled, or interruptible lock acquisition, fair queueing, or non-block-structured locking. Otherwise, prefer synchronized.

I absolutely agree because IMHO this:

synchronized (lock) {
    // ...
}

Is way more readable and less error prone than this:

try {
    lock.lock();
    // ...
} finally {
    lock.unlock();
}

Long story short: from a technical point of view, yes, you could replace synchronized with ReentrantLock, but I wouldn't do it per se.

Also checkout these questions:

Community
  • 1
  • 1
beatngu13
  • 7,201
  • 6
  • 37
  • 66
0

ReentrantLock is one of the alternatives to synchronization.

A reentrant mutual exclusion Lock with the same basic behavior and semantics as the implicit monitor lock accessed using synchronized methods and statements, but with extended capabilities.

Refer to this question for other alternatives to synchronization (Concurrent Collections, Atomic variables, Executors, ThreadLocal variables):

Avoid synchronized(this) in Java?

Community
  • 1
  • 1
Ravindra babu
  • 37,698
  • 11
  • 250
  • 211