[Haskell-cafe] Re: Chameneos

[Chris Kuklewicz]

Nice comment.

Aaron Denney wrote:
> On 2006-01-06, Chris Kuklewicz <haskell at list.mightyreason.com> wrote:
> 
>>http://www.haskell.org/hawiki/ChameneosEntry
> 
> 
> I note that 
> 
> # Like the erlang entry, this uses a separate thread to match up two
> # chameneos in the meeting room.
> 
> Which seems to me to be against the spirit of the benchmark, which
> describes itself as a "symmetrical thread rendez-vous".  Having this
> manager thread makes it assymetrical.  Yes, the Erlang entry does it
> (and it does appear to be the totally idiomatic way to do this, as one
> of the common things to do is model persistent objects as processes),
> but that doesn't necessarily mean that it is "right" to do so.
> 
> I think the intent is to have something like the Java model where 
> each thread calls some function to do the rendezvous and synchronize and
> do wakeups on shared data -- essentially move what the manager thread
> does into each color thread.
> 
> Note: I'm not saying that the seperate thread handling the rendezvous
> data structure isn't a very good and clear approach to the problem, just
> that it doesn't seem to be what the benchmark intended (unless built-in
> to the concurrency primitives provided by the language or language
> implementation).
> 

One could make an MVar version which did not use a meeting thread, and I
welcome someone to do that.  I have no proof that the current solution
is really the fastest architecture.

When I started writing solutions, I made an STM based version without
the separate meeting place thread .  This is posted on the wiki (scroll
down to the bottom two pieces) in a normal and over-annotated form.  So
it is possible to use idiomatic Haskell (STM) to create a solution.  But
some of the entries used a manager thread, so I wrote an MVar + Chan
version which instantly was faster than the STM one.  Since then I
focused on speeding up the MVar version, till not it is the winning
version.  If I can use Simon Marlow's UNBOXED ideas, then I may submit
an ever faster version.

It is possible to submit the STM version as well and they will include
it as a demonstration, but I have not bothered.  Someone else could
submit it if they cared to.

If you think about it, you will realize that if inter-process
synchronization is a bottleneck then STM will be slower.  By definition
STM aborts and throws away work if a commit fails.  Also, MVars have
wake-only-one-waiting-thread (FIFO) semantics whereas TVars and TMVars
and TChans (and all STM constructs) have wake-all-waiting-thread
semantics, even if only one can proceed.

-- 
Chris