Title: Java - Priority in semaphore
Tags: java;multithreading;semaphore
Question: I have multiple threads accessing an external resource &ndash; a broswer. But only one thread can access it at a time. So, I am using a semaphore to synchronise them. However, one thread, which takes input from the GUI and then access the browser for the results, should have priority over other threads and I am not sure how to use a semaphore to achieve it.

I was thinking that every thread after acquiring the semaphore checks if there is the priority thread waiting in the queue and if yes, then it releases it and waits again. Only the priority thread doesn't release it once it is acquired.

Is this a good solution or is there anything else in Java API I could use?


Here is the accepted answer: Here's a simple, no frills answer.  This is similar to how a read/write lock works, except that every locker has exclusive access (normally all readers proceed in parallel).  Note that it does not use ```Semaphore``` because that is almost always the wrong construct to use.

```public class PrioLock {
  private boolean _locked;
  private boolean _priorityWaiting;

  public synchronized void lock() throws InterruptedException {
    while(_locked || _priorityWaiting) {
      wait();
    }
    _locked = true;
  }

  public synchronized void lockPriority() throws InterruptedException {
    _priorityWaiting = true;
    try {
      while(_locked) {
          wait();
      }
      _locked = true;
    } finally {
      _priorityWaiting = false;
    }
  }

  public synchronized void unlock() {
    _locked = false;
    notifyAll();
  }
}
```

You would use it like one of the Lock types in java.util.concurrent:

Normal threads:

```_prioLock.lock();
try {
  // ... use resource here ...
} finally {
  _prioLock.unlock();
}
```

"Priority" thread:

```_prioLock.lockPriority();
try {
  // ... use resource here ...
} finally {
  _prioLock.unlock();
}
```

UPDATE:

Response to comment regarding "preemptive" thread interactions:

In the general sense, you cannot do that.  you could build custom functionality which added "pause points" to the locked section which would allow a low priority thread to yield to a high priority thread, but that would be fraught with peril.  

The only thing you could realistically do is interrupt the working thread causing it to exit the locked code block (assuming that your working code responded to interruption).  This would allow a high priority thread to proceed quicker at the expense of the low priority thread losing in progress work (and you might have to implement rollback logic as well).  

in order to implement this you would need to:


record the "current thread" when locking succeeds.
in ```lockPriority()```, interrupt the "current thread" if found
implement the logic between the ```lock()```/```unlock()``` (low priority) calls so that:


it responds to interruption in a reasonable time-frame
it implements any necessary "rollback" code when interrupted

potentially implement "retry" logic outside the ```lock()```/```unlock()``` (low priority) calls in order to re-do any work lost when interrupted


Comment for this answer: @jtahlborn Love the answer... though  _priorityWaiting probably should be a counter instead of boolean
Comment for this answer: @kgdinesh - responded in the answer since it was too long for a comment
Comment for this answer: @Duane - the OP stated that there is only one priority thread (and this was stated to be a "simple, no frills answer").  If you want to generalize this to a solution where you could have multiple priority threads, then, yes, _priorityWaiting would need to be a counter.  You could also have multiple levels of priorities or other fancier variants...
Comment for this answer: instead of waiting on `_locked` when `lockPriority()` is called, can we interrupt the running thread, let the priority thread finish up and then resume the previously running task?

Here is another answer: You are mixing up concepts here.

Semaphores are just one of the many options to "synchronize" the interactions of threads. They have nothing to do with thread priorities and thread scheduling. 

Thread priorities, on the other hand are a topic on its own. You have means in Java to affect them; but the results of such actions heavily depend on the underlying platform/OS; and the JVM implementation itself. In theory, using those priorities is easy, but as said; reality is more complicated.

In other words: you can only use your semaphore to ensure that only one thread is using your queue at one point in time. It doesn't help at all with ensuring that your GUI-reading thread wins over other threads when CPU cycles become a problem. But if your lucky, the answer to your problem will be simple calls to setPriority(); using different priorities.

Comment for this answer: thread priorities and lock priorities are _also_ two different concepts, and i believe you are mixing them up here.  a read/write lock is a form of locking with a simple priority mechanism (writer takes priority over readers).  OP is looking for a similar concept really (except unlike read/write lock, all lockers would presumably be exclusive).
Comment for this answer: sorry, didn't have time when i posted the comment.  have created the answer now.
Comment for this answer: Why would we want to do that? Seriously: priorities and synchronization are two **different** responsibilities. Pushing both into **one** thingy would be **plain** wrong in my eyes. Just because he wants something ... doesn't mean that giving him that would be the correct solution!
Comment for this answer: I am saying that I don't think that one should focus on using a semaphore to fix thread priority problems.
Comment for this answer: It is very simple: if you have a clear example on how using a certain semaphore would fix his problem; just put that in another answer ;-)
Comment for this answer: Without getting into terminologies, how can we actually solve what OP wants? i.e., A "semaphore-like" resource access control structure which natively understands priorities.

Here is another answer: There're no synchronization primitives in Java that would allow you to prioritise one thread over others in the manner you want.

But you could use another approach to solving your problem. Instead of synchronizing threads, make them produce small tasks (for instance, ```Runnable``` objects) and put those tasks into a ```PriorityBlockingQueue``` with tasks from the GUI thread having the highest priority. A single working thread will poll tasks from this queue and execute them. That would guarantee both mutual exclusion and prioritization.

There're special constructors in ```ThreadPoolExecutor``` that accept blocking queues. So, all you need is such an executor with a single thread provided with your ```PriorityBlockingQueue<Runnable&gt;```. Then submit your tasks to this executor and it will take care of the rest.

Should you decide to choose this approach, this post might be of interest to you: How to implement PriorityBlockingQueue with ThreadPoolExecutor and custom tasks


{'source': 'StackExchangeDataset', 'subset': 'stackoverflow.com', 'metadata': {'AnswerCount': 3, 'CommentCount': 0, 'ContentLicense': 'CC BY-SA 3.0', 'CreationDate': '2016:00:09/11/16', 'FavoriteCount': 2.0, 'PostTypeId': 1, 'Tags': '<java><multithreading><semaphore>', 'Title': 'Java - Priority in semaphore', 'ViewCount': 4501, 'id': 39437411, 'user_AboutMe': '', 'user_AccountId': 1489653.0, 'user_DisplayName': 'Ľubomír', 'user_Reputation': 915.0, 'user_Views': 65.0, 'user_id': 1397065.0}}