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.
On Tuesday, March 16, 2021 at 10:03:48 PM UTC-4 Sam Tobin-Hochstadt wrote: > 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 > > On Tue, Mar 16, 2021, 9:48 PM Greg Rosenblatt <greg....@gmail.com> wrote: > >> 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...@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 >> >> <https://groups.google.com/d/msgid/racket-users/646ab600-4655-4f5e-ad53-18eba5966fben%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/01365d33-66e7-4630-aed7-aedc66ad87f5n%40googlegroups.com.
