Re: [python-csp] Digest for python-csp@googlegroups.com - 3 Messages in 1 Topic
Andy Frances
I think the difference between a barrier and a join pattern is with a
barrier the threads synchronise on a single event (the barrier). In a
join, a thread waits for a number of events (channel operations) to
occur. In this regard, joins are not primitive and more complicated to
implement. What I believe makes joins exciting (can we actually use
that word to describe a synchronisation mechanism) is when the
underlying channel operations represent high level phenomena. Join
seems to be a gateway to complex event processing.
On 12/7/10, python-cs...@googlegroups.com
<python-cs...@googlegroups.com> wrote:
> =============================================================================
> Today's Topic Summary
> =============================================================================
>
> Group: pytho...@googlegroups.com
> Url: http://groups.google.com/group/python-csp/topics
>
> - Join Patterns [3 Updates]
> http://groups.google.com/group/python-csp/t/3a82f0017edb89f5
>
>
> =============================================================================
> Topic: Join Patterns
> Url: http://groups.google.com/group/python-csp/t/3a82f0017edb89f5
> =============================================================================
>
> ---------- 1 of 3 ----------
> From: Andrew Francis <af.sta...@gmail.com>
> Date: Dec 06 06:12AM -0800
> Url: http://groups.google.com/group/python-csp/msg/b7ad45bdd7a52af
>
> Hi Folks:
>
> I know this isn't a PyCSP question per se but has anyone looked into
> implementing join patterns? Join patterns are synchronization
> mechanism that waits for several channel operations to become ready
> before proceeding. If select/alt is about or'ing, then join is about
> and'ing. saw join patterns mentioned in the Golang-nuts mailing list a
> few months ago and the Go team didn't see quite see the point. Reading
> the literature, these things are powerful and I have seen
> implementations for Erlang, Lua, and Java. I started to do the initial
> "research" implementing join in Stackless Python (a sister CSP
> implementation of sorts) and I wondered if anyone looked at it.
>
> Cheers,
> Andrew
>
>
> ---------- 2 of 3 ----------
> From: Tony Ibbs <to...@tonyibbs.co.uk>
> Date: Dec 06 07:30PM
> Url: http://groups.google.com/group/python-csp/msg/bab66562c5a77967
>
> On 6 Dec 2010, at 14:12, Andrew Francis wrote:
>
>> implementation of sorts) and I wondered if anyone looked at it.
>
>> Cheers,
>> Andrew
>
> Possibly straying even further off topic, KBUS (a lightweight, Linux kernel
> based messaging system - I talked about it at EuroPython2010, so that's my
> interest declared) allows one to say that a message can only be delivered
> when all recipients are able to receive it (or, at least, able to have it
> added to their to-be-read queues).
>
> (KBUS is at http://code.google.com/p/kbus/, and its documentation is
> reachable from there too.)
>
> So if A, B and C have all bound to receive messages with a particular
> message name, then when S sends a message with that name, S can mark it
> "ALL OR WAIT", which means that if the incoming queues for any of A, B or C
> are full, then "send" will return -EAGAIN (the traditional Un*x way of
> indicating that one should, indeed, try again) - one can then use
> poll/select to wait for the send to succeed, or just choose to discard it
> and give up.
>
> Similarly, S can also mark the message "ALL OR FAIL", in which case the send
> will just fail (with -EBUSY) if it can't deliver to all interested
> recipients.
>
> We suspected that these would probably be most useful in debugging message
> systems, rather than in normal life. but they did seem important/interesting
> use cases.
>
> Tibs
>
>
> ---------- 3 of 3 ----------
> From: Sarah Mount <mount...@gmail.com>
> Date: Dec 06 07:50PM
> Url: http://groups.google.com/group/python-csp/msg/c1bde56119074aa
>
>> implementations for Erlang, Lua, and Java. I started to do the initial
>> "research" implementing join in Stackless Python (a sister CSP
>> implementation of sorts) and I wondered if anyone looked at it.
>
> python-csp has "barriers" which are in the csp.guards module.
>
> I believe barriers (from bulk-synchronous processing / BSP) are the
> same thing as the "join" primitives you mention. The idea of a
> barrier, is, as you say that any number of processes can "enrol" on
> the barrier, and then block until all the enrolling processes have
> synchronised on the barrier. A process can also "retire" from a
> barrier, which is the opposite of enrolling.
>
> This is a more general synchronisation primitive than ALTing, as Alt
> objects will select a single guard on which to synchronise. I think
> most modern implementations of CSP have something like barriers, JCSP
> has it and of course many implementations are derivatives of JCSP as
> the Kent group has contributed a lot to the state of the art in CSP
> implementations.
>
> Cheers,
>
> Sarah
>
> --
> Sarah Mount, Senior Lecturer, University of Wolverhampton
> website: http://www.snim2.org/
> twitter: @snim2
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "python-csp" group.
> To post to this group, send email to pytho...@googlegroups.com.
> To unsubscribe from this group, send email to
> python-csp+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/python-csp?hl=en.
>
>