[concurrency-interest] Sizing thread pools

[Ashley Williams]

Thanks for your detailed response. My assumption in all this, that I  
should have
mentioned, is that the tasks in the thread pools are self contained  
with no side
effects and so I'm not approaching this from a code safety angle -  
this is more
about performance and getting the best use out of the cpu configuration.

For IO bound tasks I am interested in finding out if the underlying OS  
io operation that
produces the data keeps going in some fashion even if the corresponding
thread that consumes it has not yet been reactivated. It would be  
great to
have confidence that even within a single core there is some sort of  
concurrency
that occurs when for example reading off a socket.

And cpu bound threads would ideally be assigned to separate cores so  
that
they can truly execute concurrently. But if the underlying scheduler  
decides to
assign them to the same core then there will be no improved performance.

So to somebody ignorant of the facts such as myself, it seems that the  
scheduler
would need some sort of clue as to how to schedule the threads otherwise
any effort to balance thread pools for size and type of task could  
well be in
vain.

On 12 Aug 2009, at 14:08, David Holmes wrote:

>
>> Ashley Williams writes:
>> It recommends that for IO bound tasks, the thread pool can be much
>> larger which makes sense since the cpu isn't the bottleneck. But  
>> say I
>> have two threads executing on a single cpu where the first is
>> executing a blocking io method and a context switch occurs to the
>> second thread. Will the underlying operating system call that the
>> first thread is waiting on still somehow still continue - eg data
>> still gets buffered for example - so that when the first thread is
>> rescheduled it has at least made some progress?
>
> That's a rather general question - there is a lot of detail that  
> determines
> exactly what may happen. For example, if the first thread has  
> initiated an
> I/O request that requires it to block, say a read from a socket, and  
> data
> arrives on that socket, then the OS will process the arrival of that  
> data in
> some form. At a minimum the interrupt of the ethernet card will be
> processed, but it could be that the thread itself is marked as no  
> longer
> blocked, and will be eligible to be switched to at the next scheduling
> point. However if the I/O thread was preempted at some arbitrary  
> point prior
> to actually initiating the I/O request and prior to blocking, then  
> it will -
> if chosen for execution again - simply continue from that point with  
> no
> "progress" having been made. And anything on-between. It depends on  
> the
> details of the blocking operation and how it is handled by the OS.
>
>> A related question - since there isn't any way to assign threads to
>> specific cpu cores from java (is this true?),
>
> It is true that there is no Java SE API for this (It will be in the
> Real-Time Specification for Java 1.1). You can do it using native  
> code.
>
>> should one always assume that any two thread executions are time- 
>> sliced?
>
> One should always strive to write portable Java programs and for  
> portability
> the golden rule with regards to scheduling is:
> - to assume that any two actions in two threads could be  
> interleaved; but
> - never require that any two actions must be interleaved
>
> In a nutshell: don't use scheduling decisions as an alternative to
> synchronization. (Even in the real-time world, with strict priority
> scheduling, you can only use scheduling as an alternative to  
> synchronization
> in very specific circumstances).
>
> I'm unclear what connection you are making between this and the  
> ability to
> bind threads to cores? If you have two threads bound on different  
> cores,
> they can not preempt each other, but they can still execute code  
> that is
> effectively interleaved - the possible interleavings are more  
> restricted,
> but as the programmer you have no idea what the relative phasing is,  
> nor how
> long individual actions take to execute. It would be difficult, and  
> very
> context sensitive, to be able to take advantage of that situation I  
> think.
> But what were you thinking of?
>
> Cheers,
> David Holmes
>