Heh, didn’t know that and independently came up with it in 30 secs - that has to be worth something ? (Although mine uses sampling of all event sources)
> On Sep 8, 2019, at 4:19 PM, burak serdar <bser...@computer.org> wrote: > >> On Sun, Sep 8, 2019 at 3:16 PM Robert Engels <reng...@ix.netcom.com> wrote: >> >> It’s hard to respond. I have done a lot of concurrent programming and >> haven’t heard the term “vector clock” so I am not sure what you > > Lamport's timestamps, vector clocks,etc: > https://en.wikipedia.org/wiki/Vector_clock > > are referring to. You can write a logical “clock cycle” by sampling > both and choosing the higher priority event - but overall performance > is going to suffer greatly. >> >> There is not such thing as “priority” across multiple resources that are >> independent - by definition the order is undefined as nothing is >> instantaneous in practice. Happens before is going to be per channel - but >> in practice the memory flush is going to occur in either case (because of >> the backing locks) but it’s not guaranteed. >> >> On Sep 8, 2019, at 10:53 AM, changkun <euryugas...@gmail.com> wrote: >> >> Hi Kurtis, >> >> I am aware that you are talking about the happen-before algorithm which is >> basically the vector clock. >> >> However, this discussion aims for the discussion regarding this proposal: >> >> "the close statement should happens-before select statement that starts >> choosing which case >> should be executing, and select a closed channel with the highest priority >> to prevent another receive case being executed once more." >> >> We are not entering write any code before we confirm that it is worthy. >> >>> On Sunday, September 8, 2019 at 5:46:43 PM UTC+2, Kurtis Rader wrote: >>> >>>> On Sun, Sep 8, 2019 at 8:40 AM changkun <euryu...@gmail.com> wrote: >>>> >>>> The provided code snipped on my machine can result in different outputs, >>>> which basically shows that it could occur in any order. >>> >>> >>> Yes >>> >>>> >>>> The randomization mechanism in select statement made the verification >>>> hard. Logically, my argument is rigorous >>> >>> >>> No, it isn't. You need to learn a lot more about concurrency and race >>> conditions. >>> >>> -- >>> Kurtis Rader >>> Caretaker of the exceptional canines Junior and Hank >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/d1c412e6-c775-49a6-8d1d-c417497dc9be%40googlegroups.com. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/297D58C7-04D4-4F6C-A6F2-62131724B071%40ix.netcom.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/AC6427E8-84E6-4718-BCB1-E6BF75D9344C%40ix.netcom.com.
