[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Declaration and deployment of threads and thread pools i

[adrian@jboss.org]

"david.lloyd at jboss.com" wrote : 
  | "adrian at jboss.org" wrote : But there are also some different policies such as MinThreadPoolExecutor so you can avoid the known race condition if you implement a WAIT policy when the thread pool is full (something that is not part of java.util.concurrent because of the race condition)
  | 
  | I saw the code and the comment to that effect, but at first glance it wasn't clear what the race condition was, or how the fix worked.  I'll have to look at that one more time...

The issue comes with small thread pools. e.g. a singleton MDB configuration
has a thread pool size of 1

Depending upon the reaping policy of unused threads it is possible for a race
condition to go something like this (I'll assume no queue although it makes
no real difference in practice since the race would still happen after dequeuing):

1) Thread 1: Submit work to the pool
2) Thread 2: Execute the work
3) Thread 2: Complete work
4) Thread 1: Submit some work - pool is busy so wait
5) Thread 2: Return thread to the pool
6) // CPU starvation for longer the idle time of threads
7) Thread 1: Stop waiting and check we have enough threads (we do)
8) Thread 2: I've been idle too long so end

So you end up with thread 1 thinking there are enough threads
to execute the work, but Thread 2 has stopped an instant after the check.

The work will never be executed unless some other thread also tries
to execute some work on the pool (meaning the number of threads gets rechecked).
For a singleton MDB with a read-ahead of messages of size  1 this never occurs
so message delivery to the MDB stalls.

The fix/work around we have is to stop step (8) from occuring.
i.e. you never allow the thread pool to go below a minimum of one thread
which avoids the race condition - there is always at least one thread
available to execute the work.

The real fix would be to make the check in step (7) more atomic
i.e. move the thread pool size check to later when it tries to execute the work
but that's not easy to do if you look at the code. :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187346#4187346

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187346