On 2011-11-17 5:39 PM, John Clements wrote: > If I'm reading the docs correctly, the principal advantage of the > asynchronous buffers is actually their buffered nature, which makes > it more likely that the messages will be received in the "right" > order. That, and possibly the fact that the buffer takes less memory > than a stalled thread.
I've played with the code for async buffered channels recently. I reckon you've mentioned two important advantages, but there are a couple of additional things worth mentioning. Your points first: 1. Ordering is preserved with async buffered channels 2. Per-message overhead of a queued message is low but in addition: 3. Message ownership is transferred at point of send 4. The queue is kill-safe By (3) I mean that (thread (lambda () (channel-put c datum))) is part of the sender's thread group, so if the sender is shut down before the message is delivered, the message is "retracted" and no longer available for receipt. When using an async buffered channel, the message is transferred into the control of the channel's manager thread, which generally resists being shut down (per the kill-safety paper [[1]]). Even if the sending thread dies or is shut down, the message remains in the queue for eventual receipt. For (4), see [[1]]; the idea basically is that by carefully scoping the lifetime of the manager thread, and having it do all the data-structure manipulation, it becomes impossible for arbitrary crashes of clients to leave the queue in an inconsistent state. (Synchronous channels form a kind of primitive/atomic kill-safe communication mechanism, out of which the larger ones are built.) Of course that's not an issue with your thread-for-channel-put approach, though. Cheers, Tony [[1]] M. Flatt and R. B. Findler, "Kill-safe synchronization abstractions," ACM SIGPLAN Notices, vol. 39, no. 6, p. 47, Jun. 2004. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
