How many std.concurrency receivers?

[thedeemon]

On Thursday, 11 October 2012 at 18:43:37 UTC, Russel Winder wrote:

> Can't this be done now using tasks and a threadpool from 
> std.parallel?

As far as I understand that would essentially mean a single queue 
of tasks which is accessed concurrently by workers hungry of work 
(one point of locking), and if one cell receives two messages 
with little time interval inbetween then two different threads 
can pick up the tasks of reacting to those messages and run in 
parallel which means two threads may try to change cell's state 
simultaneously unless you add a lock to each cell or somehow 
organize pinning cells to particular threads. Doesn't look good 
to me, unless there is a very different design.

> And I believe (in that I can't point you at explicit data just 
> now),
> that it is generally best to have 1 or 2 more threads than 
> there are cores to get optimal performance.

I guess it depends very much on the tasks being executed. If they 
do some I/O or other blocking operations, additional threads may 
indeed help keep CPU cores busy.