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 <mfl...@cs.utah.edu> 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 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 >> . >> > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/646ab600-4655-4f5e-ad53-18eba5966fben%40googlegroups.com.
