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?
On Monday, March 15, 2021 at 8:12:03 PM UTC-4 Sam Tobin-Hochstadt wrote: > I think Aaron Turon's reagents (and more generally k-cas) are an example > of N-way rendezvous. > > Sam > > On Mon, Mar 15, 2021, 5:50 PM Matthew Flatt <[email protected]> wrote: > >> 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 >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-users/20210315155008.cc%40sirmail.smtps.cs.utah.edu >> . >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/646ab600-4655-4f5e-ad53-18eba5966fben%40googlegroups.com.
