Re: [Haskell-cafe] Re: Chameneos

Nice comment. Aaron Denney wrote:

On 2006-01-06, Chris Kuklewicz 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