Re: [racket-users] Synchronizable conjunction of events?

[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=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  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  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
>>  
>> 
>> .
>>
>

-- 
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.

Re: [racket-users] Synchronizable conjunction of events?

[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

On Tue, Mar 16, 2021, 9:48 PM Greg Rosenblatt  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  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
> 
> .
>

-- 
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/CAK%3DHD%2BaXvUNarLG%2BtWFB_0Wive-h4dJrOMmPLVoYaWc0qWt0tA%40mail.gmail.com.

Re: [racket-users] Synchronizable conjunction of events?

[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?

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  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.

Re: [racket-users] Synchronizable conjunction of events?

[Sam Tobin-Hochstadt]

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  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+unsubscr...@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/CAK%3DHD%2BYF0eQX%2B0oZCEs_E6XAF6Hv4vaA0tTTfEky%3DL7B7YAj-g%40mail.gmail.com.

Re: [racket-users] Synchronizable conjunction of events?

[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

On Mon, Mar 15, 2021 at 4:50 PM Matthew Flatt  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+unsubscr...@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/CAL3TdONtWDeMgWUzXB%3DWc-fN%3DRi2pj%2BMC7-kg5pWhJOc2bzgjA%40mail.gmail.com.

Re: [racket-users] Synchronizable conjunction of events?

[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

-- 
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/20210315155008.cc%40sirmail.smtps.cs.utah.edu.

[racket-users] 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.

-- 
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/1c879735-ee18-40d5-b4a5-3dd12dfe248an%40googlegroups.com.