• Post Reply Bookmark Topic Watch Topic
  • New Topic

Multi-threading order of submission and completion

 
Steven Chu
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Trying to understand the following example.

Namely, could it ever be the case that a task is submitted and gets completed before the next task is submitted? (Lines 58, 59) If this were the case, then a deadlock might potentially not happen for this particular example, correct?

I understand the the purpose of the Thread.sleep(100) line is to give other threads a chance to do some work. But I'm asking the question, "could it ever be the case that there might not be another thread available?" I know that 10 threads are allocated for this pool, so I guess my main confusion regards how can I be absolutely sure that a deadlock will occur here? Ancillary confusion has to do with things like understanding whether or not the order of submit() calls matter, and when exactly the pool gets populated with tasks.

Note: this comes from the OCP book in the chapter on concurrency - specifically, the "Identifying Threading Problems" section.

 
Les Morgan
Rancher
Posts: 717
17
C++ Java MySQL Database Netbeans IDE Oracle Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a 8 core CPU at work, it is dual threaded in each CORE, so it has 16 threads to play with. In everything I do, which is mostly IO bottled, I have never seen more than 20% CPU and when I do multithreaded apps, there is that rare case that they will be blocking. If you want to be sure to have your threads block, make your resource they will access wait/sleep or loop without yeild while being accessed.
 
Henry Wong
author
Sheriff
Posts: 22532
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Steven Chu wrote:I understand the the purpose of the Thread.sleep(100) line is to give other threads a chance to do some work. But I'm asking the question, "could it ever be the case that there might not be another thread available?" I know that 10 threads are allocated for this pool, so I guess my main confusion regards how can I be absolutely sure that a deadlock will occur here? Ancillary confusion has to do with things like understanding whether or not the order of submit() calls matter, and when exactly the pool gets populated with tasks.


Race conditions, along with deadlocks that can be triggered, isn't only a problem when you can "be absolutely sure that a deadlock will occur". It is a problem even if it never occurs for you !!

Imagine that you never facing it in your testing, but it deadlocks with some of your customers, with different versions of JVM on different machines with different timings. Imagine it runs fine with you because you are single threaded, but it deadlocks with some of your customers, because they use your library in a thread fashion. These are issues -- even if they never deadlock for you !!

You need to examine your code at the other extreme, and deal with it... and not wait until you are absolutely sure that it will occur before you deal with it.

Henry
 
Steven Chu
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey folks. Thanks so much for your answers. I really appreciate people taking the time.

But I may have been unclear in what I was looking for. The bolded question suggests that I'm trying to create a deadlock. This is not the case!

I was asking that question because the book I'm studying OCP Certification Study Guide (Boyarsky and Selikoff) suggests that every time I run this program, I will run into a deadlock. I want to know if this is true.

Specifically, I'm wondering whether or not the following could or could not happen.

1. main thread (M) submits first task
2. in pool, first thread (A) submits task
3. in pool, first thread (A) completes task, meaning eatAndDrink() method (notably, including the Thread.sleep(100) call) happens in one fell swoop

ALL before the second task was submitted, and a new thread (B) created for it.

Is this possible?

Thanks!

 
Henry Wong
author
Sheriff
Posts: 22532
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Steven Chu wrote:
Specifically, I'm wondering whether or not the following could or could not happen.

1. main thread (M) submits first task
2. in pool, first thread (A) submits task
3. in pool, first thread (A) completes task, meaning eatAndDrink() method (notably, including the Thread.sleep(100) call) happens in one fell swoop

ALL before the second task was submitted, and a new thread (B) created for it.

Is this possible?


Possible? Yes. How possible? Unlikely. You would have to do a lot of work to accomplish it.

Keep in mind that a computer may do dozens of time slices per second (with perhaps, a time slice lasting around 20 milliseconds). Also, a sleep call doesn't actually need the processor, so it can run other threads (sleeping threads aren't runnable). Additionally, this assumes a single core CPU, where it has to actually time slice -- with multi core/processor, these threads will run in parallel (and time slicing won't even be done).

So, if you use a very old machine, that is single core and runs at a lower HZs (so time slices may be longer); and you get the right OS and JVM combination; and you overload that machine with other processes so that it is unable to time slice to the main thread that starts the second thread, then yes, I guess you can get it to happen.

Henry
 
Scott Selikoff
author
Bartender
Posts: 4033
18
Eclipse IDE Flex Google Web Toolkit
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In our OCP book, the first two paragraphs in the Deadlock describe a "conceptual" scenario where deadlock can occur (like the dining philosopher problem), while the Fox class underneath "models this behavior." Is it possible the code will not enter deadlock? Definitely.

In fact, the book never guarantees this code will enter deadlock. It just tries to provide a concrete example to a descriptive story. The "Thread.sleep(100)" is an artificial delay to encourage (in the vast majority of executions) that the code will deadlock, but on a really over-taxed system it might finish in serially.

The key here is to understand the concept of deadlock, hence the descriptive example and story.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!