File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Priority Semaphore/Lock

 
Michael Golightly
Greenhorn
Posts: 29
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a situation where I have multiple threads running. One of them is a consumer of a shared data map, while the others are producing into the map. Because the producers will be putting more than one item into the map at a time, I need each of the threads to behave essentially in an atomic way. I can accomplish this by synchronizing the shared map, but it presents another problem. The consumer thread will be sleeping for some number of seconds, then waking up, taking everything off the map and pushing that data elsewhere. When the consumer thread wakes up, I want it to take priority over the data map so that if any of the producers are waiting to take control using the synchronized block (while another producer is processing), the consumer runs before they do. Essentially what I am looking for is some sort of priority semaphore or locking mechanism that will allow the consumer to be next in the list to use the data map. I'm looking into the java.util.concurrent package, but nothing is jumping out at me yet. I'll continue to research, but figured I'd ask the experts too.

Edit: I should mention that I'm not partial to semaphores, it can be any implementation.
 
Henry Wong
author
Marshal
Pie
Posts: 20831
75
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Michael Golightly wrote:I have a situation where I have multiple threads running. One of them is a consumer of a shared data map, while the others are producing into the map. Because the producers will be putting more than one item into the map at a time, I need each of the threads to behave essentially in an atomic way. I can accomplish this by synchronizing the shared map, but it presents another problem. The consumer thread will be sleeping for some number of seconds, then waking up, taking everything off the map and pushing that data elsewhere. When the consumer thread wakes up, I want it to take priority over the data map so that if any of the producers are waiting to take control using the synchronized block (while another producer is processing), the consumer runs before they do. Essentially what I am looking for is some sort of priority semaphore or locking mechanism that will allow the consumer to be next in the list to use the data map. I'm looking into the java.util.concurrent package, but nothing is jumping out at me yet. I'll continue to research, but figured I'd ask the experts too.

Edit: I should mention that I'm not partial to semaphores, it can be any implementation.



I don't think priority is supported, by either the Lock (ReentrantLock) or Semaphore class. The best you can do is to have fairness enabled. This will guaranteed that no lock grab "skips the line", and hence, make sure that the consumer thread doesn't starve from the producers.


Now, in thinking about it a bit more, you can simulate what you want easily by using two locks. Have the producer grab lock A, then lock B, before processing. The second lock (lock B) should be an uncontended lock grab since all the producers should be blocked on A. Later, when the one consumers wants the lock, it simply grabs Lock B (it skips grabbing A). Since the consumer is the only thread waiting for lock B, because the other producers are on Lock A, it will get it as soon as the currently running producer releases it. As for the next producer, it will wait on Lock B, until the consumer releases it.

Henry
 
Michael Golightly
Greenhorn
Posts: 29
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:
Michael Golightly wrote:I have a situation where I have multiple threads running. One of them is a consumer of a shared data map, while the others are producing into the map. Because the producers will be putting more than one item into the map at a time, I need each of the threads to behave essentially in an atomic way. I can accomplish this by synchronizing the shared map, but it presents another problem. The consumer thread will be sleeping for some number of seconds, then waking up, taking everything off the map and pushing that data elsewhere. When the consumer thread wakes up, I want it to take priority over the data map so that if any of the producers are waiting to take control using the synchronized block (while another producer is processing), the consumer runs before they do. Essentially what I am looking for is some sort of priority semaphore or locking mechanism that will allow the consumer to be next in the list to use the data map. I'm looking into the java.util.concurrent package, but nothing is jumping out at me yet. I'll continue to research, but figured I'd ask the experts too.

Edit: I should mention that I'm not partial to semaphores, it can be any implementation.



I don't think priority is supported, by either the Lock (ReentrantLock) or Semaphore class. The best you can do is to have fairness enabled. This will guaranteed that no lock grab "skips the line", and hence, make sure that the consumer thread doesn't starve from the producers.


Now, in thinking about it a bit more, you can simulate what you want easily by using two locks. Have the producer grab lock A, then lock B, before processing. The second lock (lock B) should be an uncontended lock grab since all the producers should be blocked on A. Later, when the one consumers wants the lock, it simply grabs Lock B (it skips grabbing A). Since the consumer is the only thread waiting for lock B, because the other producers are on Lock A, it will get it as soon as the currently running producer releases it. As for the next producer, it will wait on Lock B, until the consumer releases it.

Henry


I like love that idea. Does it not have the problem of the producer holding lock A and B releasing A and B and a second producer grabbing A and B before the consumer is awakened to grab B? Even if this is possible, the chance seems to be remarkably low.
 
Henry Wong
author
Marshal
Pie
Posts: 20831
75
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Michael Golightly wrote:
Henry Wong wrote:Now, in thinking about it a bit more, you can simulate what you want easily by using two locks. Have the producer grab lock A, then lock B, before processing. The second lock (lock B) should be an uncontended lock grab since all the producers should be blocked on A. Later, when the one consumers wants the lock, it simply grabs Lock B (it skips grabbing A). Since the consumer is the only thread waiting for lock B, because the other producers are on Lock A, it will get it as soon as the currently running producer releases it. As for the next producer, it will wait on Lock B, until the consumer releases it.


I like love that idea. Does it not have the problem of the producer holding lock A and B releasing A and B and a second producer grabbing A and B before the consumer is awakened to grab B? Even if this is possible, the chance seems to be remarkably low.



If Lock B is configured to be fair. This case will be impossible. The thread that requests Lock B first will get it -- it will be impossible for a producer to get Lock A and then Lock B, with a consumer already waiting on Lock B.

Henry
 
Michael Golightly
Greenhorn
Posts: 29
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:
Michael Golightly wrote:
Henry Wong wrote:Now, in thinking about it a bit more, you can simulate what you want easily by using two locks. Have the producer grab lock A, then lock B, before processing. The second lock (lock B) should be an uncontended lock grab since all the producers should be blocked on A. Later, when the one consumers wants the lock, it simply grabs Lock B (it skips grabbing A). Since the consumer is the only thread waiting for lock B, because the other producers are on Lock A, it will get it as soon as the currently running producer releases it. As for the next producer, it will wait on Lock B, until the consumer releases it.


I like love that idea. Does it not have the problem of the producer holding lock A and B releasing A and B and a second producer grabbing A and B before the consumer is awakened to grab B? Even if this is possible, the chance seems to be remarkably low.



If Lock B is configured to be fair. This case will be impossible. The thread that requests Lock B first will get it -- it will be impossible for a producer to get Lock A and then Lock B, with a consumer already waiting on Lock B.

Henry

Excellent, I'm running a test on it now to make sure it behaves the way I want it to.
 
Michael Golightly
Greenhorn
Posts: 29
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This appears to be working. Can you see any glaring problems?

 
Henry Wong
author
Marshal
Pie
Posts: 20831
75
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Michael Golightly wrote:This appears to be working. Can you see any glaring problems?


Looks fine. The only issue that I can think of is that this is a simple lock -- meaning no support of condition variables. If this is what you need, then great.

Henry
 
Michael Golightly
Greenhorn
Posts: 29
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:
Michael Golightly wrote:This appears to be working. Can you see any glaring problems?


Looks fine. The only issue that I can think of is that this is a simple lock -- meaning no support of condition variables. If this is what you need, then great.

Henry

For what I need it for, this works. It's a simple lock without any fancy bells and whistles.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic