Synchronizable conjunction of events?

[Greg Rosenblatt]

Some context for my question: `choice-evt` constructs an event that behaves analogously to a logical disjunction, choosing any of its members that is ready for synchronization.

Is there a corresponding event for a logical conjunction (I was looking for something like `all-evt` or `every-evt`), which requires that all of its members be ready for synchronization at the same time?  If not, is there a fundamental barrier to its implementation with the ConcurrentML approach?

Related to this, I've been reading "Kill-Safe Synchronization Abstractions" (https://www.cs.utah.edu/plt/publications/pldi04-ff.pdf), and found it notable that the swap channel couldn't be implemented in a way that was both kill-safe and break-safe (not ruining `sync/enable-break`'s exclusive-or guarantee).  I'm wondering if both forms of safety could be achieved by using a hypothetical `all-evt` that behaves as I've described.

[Matthew Flatt]

At Mon, 15 Mar 2021 13:38:46 -0700 (PDT), Greg Rosenblatt wrote:
> Is there a corresponding event for a logical conjunction (I was looking for
> something like `all-evt` or `every-evt`), which requires that all of its
> members be ready for synchronization at the same time?

No. (Although `replavce-evt` is a weak kind of "and", it's not what
you're looking for.)

> If not, is there a fundamental barrier to its implementation with the
> ConcurrentML approach?

Yes, at least in the sense that it's not possible to implement N-way
rendezvous given only CML's rendezvous.

So, N-way rendezvous would have to be implemented in the core. I'm
certain that some languages have implemented that, but I have forgotten
the examples.

> Related to this, I've been reading "Kill-Safe Synchronization Abstractions"
> (https://www.cs.utah.edu/plt/publications/pldi04-ff.pdf), and found it
> notable that the swap channel couldn't be implemented in a way that was
> both kill-safe and break-safe (not ruining `sync/enable-break`'s
> exclusive-or guarantee). I'm wondering if both forms of safety could be
> achieved by using a hypothetical `all-evt` that behaves as I've described.

Probably so. The citation of [17] in that part of the paper is meant to
allude to the CML-style rendezvous versus N-way rendezvous constraint.


Matthew

[Robby Findler]

Depending on what you're doing, a nack guard evt might be helpful. It lets do a form of chaining evts together. It definitely isn't and in the sense you describe but it is easy to overlook. 

Robby

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20210315155008.cc%40sirmail.smtps.cs.utah.edu.

[Sam Tobin-Hochstadt]

I think Aaron Turon's reagents (and more generally k-cas) are an example of N-way rendezvous. 

Sam

[Greg Rosenblatt]

Thanks for the help, everyone.

Sam, it looks like you've worked with Aaron a bit on reagents in https://github.com/aturon/Caper.  Is there anything CML can express that reagents have trouble with?  How does the implementation complexity compare?

[Sam Tobin-Hochstadt]

Reagents are a generalization of core CML, but Racket extends the basics of CML considerably. I think there's definitely implementation complexity in reagents that would need to be added to support conjunction, but I don't know how much. 

Looking back at Aaron's thesis, I see several other systems with forms of conjunction that are relevant here. First, join patterns, which reagents are based on, also include conjunction. Second, transactional events (Donnelly and Fluent) are in some sense exactly what's requested here, the andThen combinator mentioned here is what I think you originally requested: http://www.cs.cornell.edu/people/fluet/research/tx-events/

Sam

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/646ab600-4655-4f5e-ad53-18eba5966fben%40googlegroups.com.

[Greg Rosenblatt]

Thanks for the info, lots of reading to do now.

I ran across transactional events, and also "Isolates: Serializability Enforcement for Concurrent ML" (https://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=2730&context=cstech) which looks like it may extend transactional events.