How many std.concurrency receivers?

[Russel Winder]

On Thu, 2012-10-11 at 21:26 +0200, thedeemon wrote:
> 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.

Many actor systems that deal with very large numbers of messages per
second are based on single threaded event-driven engines. JActor,
PyActor, etc.

Alternatively use Concurrent Sequential Processes. The key here is
concurrent, sequential, processes :-) Python-CSP has them. PyCSP has
them. Go has them. C++CSP2 has them. JCSP has them. GroovyCSP has them.
It's all about the sequential processes and the rendezvous semantics.
And also the select operation.

> > 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.

Cores being busy is not an important metric. Number of useful
applications actions is far more important, even if this means most
cores are idle most of the time.

The rational for more threads than cores is indeed blocking, be it I/O
or otherwise. The serious problem is cache-line contention, which is
where Threading Building Blocks makes a big win.

Sadly I seem to have used examples none of which relate to D :-(

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20121011/df5aad4f/attachment.pgp>