• Post Reply Bookmark Topic Watch Topic
  • New Topic

Questions regarding a simple producer-consumer problem.  RSS feed

 
ven jovovich
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
In the below program, I have one producer thread (t1) which takes input from the user and writes
it to an object "Drop". There is a controller thread (t2) which controls the three consumer
threads consumer1Thread, consumer2Thread and consumer3Thread (I added this controller thread just
for fun, we could have done directly with the three consumer threads). These three consumer
threads will read an object (Drop) and print it's value.
What I can't figure out is how to make the producer thread wait while the consumer threads are
sleeping. In other words, say that "consumer1Thread" has read "Drop" and the other two consumer
threads are sleeping, this is exactly when I do NOT want the producer thread to ask for an input
(is this a state when the JVM executes no thread(s)?).
... and to make matters worse, what if I had more than 3 consumer threads which would sleep for
random time intervals?

Below is my code (based somewhat on code from The Java Tutorials):



Please enlighten me .

Regards,
Ven Jovovich.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ven jovovich wrote:
What I can't figure out is how to make the producer thread wait while the consumer threads are
sleeping. In other words, say that "consumer1Thread" has read "Drop" and the other two consumer
threads are sleeping, this is exactly when I do NOT want the producer thread to ask for an input


This doesn't make sense. The producer shouldn't care what the consumers are doing. That's the reason we decouple them and make it multithreaded--producing and consuming are independent tasks.

However, if you really want to do that, then you'd have to have a shared variable for each thread, or else a single shared counter variable. When a consumer is about to sleep or is about to start working on an item from the Drop, it sets its flag or increments the counter. The producer would loop in a check flags/wait() loop until a consumer is ready. Or you could use the constructs in java.util.concurrent to the same effect.

(is this a state when the JVM executes no thread(s)?).


No clue what you're saying here.

... and to make matters worse, what if I had more than 3 consumer threads which would sleep for
random time intervals?


Same advice applies: Don't do it that way, but if you're going to, here's how.

Also, why are your consumers sleeping in the first place?
 
ven jovovich
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot Jeff.


This doesn't make sense. The producer shouldn't care what the consumers are doing. That's the reason we decouple them and make it multithreaded--producing and consuming are independent tasks.

Excellent point you got there... maybe I was thinking too much about threads and lost sight of the basics....

(is this a state when the JVM executes no thread(s)?).

No clue what you're saying here.

What I meant was, the producer thread is sleeping (or waiting) for the consumer threads to complete and the consumer threads are in turn sleeping, so the JVM is not executing any thread(s) except keeping track of how long the consumer threads have slept, so is the JVM in a state in which it executes no threads?


Also, why are your consumers sleeping in the first place?

I wanted to make sure that the producer would have a chance to run but it won't.

Regards,
Ven.
 
Paul Clapham
Sheriff
Posts: 22823
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, it's certainly possible that all of your application threads could be waiting. Did you consider that to be a potential problem? If so, why?
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ven jovovich wrote:
Jeff Verdegan wrote:
ven jovovich wrote:(is this a state when the JVM executes no thread(s)?).

No clue what you're saying here.

What I meant was, the producer thread is sleeping (or waiting) for the consumer threads to complete and the consumer threads are in turn sleeping, so the JVM is not executing any thread(s) except keeping track of how long the consumer threads have slept, so is the JVM in a state in which it executes no threads?


Yes, it is possible to get to a state where none of your threads are executing, because they're all blocked on I/O, waiting on a lock, or sleeping. That may happen simply as a matter of course when there's no work to do, or it may happen as a result of an error in design or coding.



Also, why are your consumers sleeping in the first place?

I wanted to make sure that the producer would have a chance to run but it won't.


We don't sleep to give other threads a chance to run. We don't do anything to give other threads a chance to run, except maybe set threads' priorities to possibly give some diesred shape to the distribution (although even that does not have well defined results). The JVM takes care of scheduling for us. The only reason you would sleep is if you want your current thread to stop working for some time, for its own reasons.
 
ven jovovich
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:Yes, it's certainly possible that all of your application threads could be waiting. Did you consider that to be a potential problem? If so, why?

Thanks Paul. This was just a toy program I was trying... but yes it is a problem because my program has not completed executing, yet it is doing nothing, on the contrary it is may have acquired some locks (sleeping). Sounds like deadlock-for-a-short-interval-of-time. It would be nice if you would add your views to this.

Jeff Verdegan wrote:
We don't sleep to give other threads a chance to run. We don't do anything to give other threads a chance to run, except maybe set threads' priorities to possibly give some desired shape to the distribution (although even that does not have well defined results). The JVM takes care of scheduling for us. The only reason you would sleep is if you want your current thread to stop working for some time, for its own reasons.

Thanks Jeff. Agreed 100%. This was just a toy program that I was experimenting with and had spared no thoughts on design, all I wanted (blindly) was to give the producer a chance to run. Surely I will keep these things in mind from now on.

Regards,
Ven.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ven jovovich wrote:
Jeff Verdegan wrote:
We don't sleep to give other threads a chance to run. We don't do anything to give other threads a chance to run, except maybe set threads' priorities to possibly give some desired shape to the distribution (although even that does not have well defined results). The JVM takes care of scheduling for us. The only reason you would sleep is if you want your current thread to stop working for some time, for its own reasons.

Thanks Jeff. Agreed 100%. This was just a toy program that I was experimenting with and had spared no thoughts on design, all I wanted (blindly) was to give the producer a chance to run. Surely I will keep these things in mind from now on.


Let me actually qualify my previous comment a bit.

We don't sleep to give other threads a chance to run in real code. However, when playing around with multithreaded code for educational purposes, if you want a simple program that doesn't do I/O and doesn't do a bunch of long calculations, but still want your various threads to have their turns, a sleep() call can be an acceptable way to do that.

If there's not a lot of CPU work to do, and no I/O to block on, any thread we start will probably just run to completion in a single time slice, so a sleep() call may give other threads a chance to run concurrently with each other, not because the JVM needs us to tell it to take turns, but just because otherwise the threads' are so short-lived that there's no point in swapping one out before it's done.

I hope that makes sense.

As for your program hanging, sleep() is definitely NOT a solution to that. Other mechanisms to control which threads can and cannot run may be warranted though.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!