Concurrency models (was: Timer)

[Alan Kennedy]

[Cameron Laird]
> This thread is really about asynchronous or concurrent 
> processing, 

I really don't have time to post to the level of detail I would like,
but I had to put forward a couple of thoughts.

> I claim, and I further claim we really don't 
> have *any* satisfying model for coding those.

I think you might get some disagreement from the Twisted, Medusa and
ZServer people. And possibly see a slanging match erupt on whose
design is best....

> Threading 
> is a quagmire (everyone agree?), 

Definitely. Sometimes.

I think threads are really a useful abstraction for programmers who
are learning to deal with developing servers for the first time. And
threads fulfill their function very well, to a point. 

But they have fundamental scalability problems: The C10K problem
illustrates this well: Surely it should be possible for a modern
computer, with giga-everything (!), to serve 10,000 clients
simultaneously?

http://www.kegel.com/c10k.html

To go beyond the performance limits imposed by the resource-hogging
threads (OMG, > 1MB of core on some platforms!), it's necessary to
move to a different concurrency mechanism, such as coroutines, which
represents "tasklets" much more efficiently.

But event-based concurrency models suffer from a fundamental
limitation: it is more difficult to spread work across multiple
processors. CPython, to some degree, lets event-based developers off
the hook, because the presence of the GIL allows them to not address
the problem, because it wouldn't achieve anything anyway.....

And the patchy support for SSL in asynch frameworks is another
fundamental problem.

Another point in favour of threads: On a multi-processor box, the
thread abstraction generally "automagically" gives you free migration
to other processors. You (generally) don't have to change a line of
your code: the underlying [OS|VM] takes care of it.

> and our guild has demonstrated only marginally more 
> reliability in working with,
> say, co-routines, chords, continuations, and so on. For 
> my money, the event-oriented model behind the [after] 
> above is at least as robust as any other.

FWIW, I think that Java has a very nice model for asynchronous IO,
with all "selectors" being thread-safe, so that "selectables" that are
ready for IO can be processed in another thread, i.e. potentially on
another processor, thus giving the best of both worlds.

http://java.sun.com/j2se/1.4.2/docs/api/java/nio/package-summary.html

> Among other frailties, I hold a grudge against the aca- 
> demic world that it hasn't shown more leadership in this 
> matter. 

Googling for "'high performance' asynchronous server" shows that both
Academia and Industry are certainly not short of powerpoint-ware on
the subject......

> I'll summarize: validation of event-oriented designs 
> implemented with [after] and similar mechanisms, is at 
> worst no more difficult than validation of the corre- 
> sponding thread-based designs. Concurrency is hard to 
> get right, at least with our current understanding. 

My €0,02: Generators (and, by extension, coroutines) will be python's
greatest advance in simplifying writing event-based server
architectures: resumable functions are a honking great idea.

regards,

-- 
alan kennedy 
----------------------------------------------------- 
check http headers here: http://xhaus.com/headers 
email alan: http://xhaus.com/mailto/alan