0

I am looking out for a way in java, by which we can achieve time based locking for java threads OR may be time based interruption. consider this.

A java thread calls following function,

private DATA getData() {
   DATA data;
   synchronized(dataLock) {
       data = fetchData()
   }
   return data
}

Now assume call to fetchData() is hung, doesn't return. is there a way to timeout on this lock(dataLock) here, or interrupt this thread ?

Curious George
  • 159
  • 2
  • 3
  • 8
  • Possible duplicate of [Using Timeout to avoid deadlock in Java multithreading](https://stackoverflow.com/questions/13741479/using-timeout-to-avoid-deadlock-in-java-multithreading) – Bagus Tesa Sep 18 '17 at 11:21
  • 1
    I don't see why the lock is relevant. If the method `fetchData()` doesn't (somehow) time-out a 1 threaded application will hang. If it does time-out then a multi-threaded application will on return from `fetchData()` (or when it throws a time-out exception) release the `dataLock`. The question here is really "is there a time-out constrained way of calling `fetchData()`) to which the answer is 'no idea'. What does `fetchData()` do. Must libraries offer some time-out capability or even an asynchronous 'cancel' method or (in Java) if 'fetchData()` is using an interruptible channel (or similar). – Persixty Sep 18 '17 at 11:57
  • @Persixty, method 'getData()' shall be called by multiple threads, assume 'fetchData()' once stuck, would never return/timeout. Here I was trying to find a "time based locking" alternative of 'synchronized(dataLock)' call. – Curious George Sep 18 '17 at 14:17
  • 3
    Ditto what Persixty said: The real problem is how to "unstick" a `fetchData()` call. That question has nothing to do with threads or locks, and you can only answer it by looking at the `fetchData()` implementation. If there's no way to "unstick" it, then maybe you can change your architecture so that `fetchData()` is called in a subordinate process that you can kill and re-start if needed. (Been there! Done that!) – Solomon Slow Sep 18 '17 at 14:53
  • 1
    @jameslarge Exactly. Work out a way to 'unstick' `fetchData()` and the lock isn't a problem. Fail to find a way to 'unstick' `fectData()` and the lock is irrelevant. What library or source is `fetchData()` using? Can you post the methods code? – Persixty Sep 18 '17 at 17:10
  • @jameslarge : Thanks for suggestion, this sounds good to use a subordinate process to call `fetchData()`. Considering you have no control on `fetchData()`, it a third-party library method. – Curious George Sep 19 '17 at 05:48
  • @Persixty: Its a generic problem I stumbled upon, was trying to figure out a solution for it. – Curious George Sep 19 '17 at 05:49
  • @CuriousGeorge It is and the answer is in making `fetchData()` time-out or be interruptible (say if it normally blocks until input arrives). No manipulation of the lock will get you anywhere without that facility on `fetchData()`. – Persixty Sep 19 '17 at 06:13

1 Answers1

5

Use the more flexible Lock interface (i.e. for example ReentrantLock), which allows you to call tryLock(long time, TimeUnit unit) to prevent waiting forever.

Kayaman
  • 72,141
  • 5
  • 83
  • 121
  • 2
    Thanks for comment @Kayaman, but the requirement is different. Its not about timing other threads, rather timing out this thread. – Curious George Sep 18 '17 at 11:22
  • 4
    That depends on the `fetchData()` method itself. You can of course interrupt the thread and hope that's enough to stop it doing whatever it's doing. You could subclass a lock implementation to provide access to the `Thread` that's currently holding the lock (it's a protected method in `ReentrantLock`). – Kayaman Sep 18 '17 at 11:28
  • @CuriousGeorge I think the above answer suffices of timing out current thread. Please be clear on "Its not about timing other threads, rather timing out this thread" – Aarish Ramesh Sep 18 '17 at 11:32
  • @Kayaman, thanks for the idea, I can have some work around this. – Curious George Sep 18 '17 at 11:42
  • @Aarish, What I meant was, instead of other threads calling `tryLock(timeout, unit)`, and timing out on this lock. Was looking for something such that while acquiring a lock, if we could specify a timeout, so that after acquiring lock, if current thread is stuck forever for some reason, it would be interrupted. – Curious George Sep 18 '17 at 11:49
  • 1
    No, there's no such built-in transaction functionality in any programming language that I know of. If a thread gets stuck, another thread is needed to try to interrupt it. Emphasis on *try*. There's no guarantee that you can timeout a runaway thread. – Kayaman Sep 18 '17 at 11:52
  • @Kayaman I also have similar question related to locking [here](https://stackoverflow.com/questions/47107331/how-to-make-sure-that-i-am-not-sharing-same-socket-between-two-threads-at-a-same). Wanted to see if you can help me out. – john Nov 10 '17 at 16:49