fredag 7. mai 2021 kl. 04:10:42 UTC+2 skrev Ian Lance Taylor: > On Thu, May 6, 2021 at 6:40 AM 'Axel Wagner' via golang-nuts > <golan...@googlegroups.com> wrote: > > > > FWIW after all this discussion I *am* curious about a more detailed > argument for why we can't have a priority select that guarantees that if > the high-priority case becomes ready before the low-priority one (in the > sense of "there exists a happens-before edge according to the memory > model"), the high-priority will always be chosen. > > > > That is, in the example I posted above, we do know that `hi` becoming > readable happens-before `lo` becoming readable, so a true prioritized > select would always choose `hi` and never return. The construct we > presented does return. > > > > Now, I do 100% agree that it's not possible to have a select that > guarantees that `hi` will be read if both become readable concurrently. But > I don't see a fundamental issue with having a select that always chooses > `hi` if `hi` becoming readable happens-before `lo` becoming readable. > > > > And to be clear, I also kinda like that we don't have that - I think the > value provided by the pseudo-random choice in preventing starvation is > worth not having an "ideal" priority select construct in the language. But > I couldn't really make a good case why we can't have it. > > I believe that we could implement a select statement that supports > priority cases, such that when multiple cases are ready, and at least > one is a priority case, then we would always choose one of the > priority cases. > > The reason we don't have such a feature is not because of > implementation difficulty. It's because the feature isn't needed,
..I hope you mean "isn't needed in Go"? There are at least the two cases, which I think that you would say would not pertain to Go (fair enough!) (1) priority of one select case over another (which in the non-Go example might be exemplified as an alternative to prioritised interrupts, which much HW find useful, even necessary) (2) a means to enable the programmer to design his/her own "fair" handling in servers, of clients (but for Go "fair" is always random/nondeterministic). > and > because, as this thread indicates, it tends to confuse people. I think the main reason for the confusion was that many tried to understand the select-pri-default-select-hi-lo code example? Or is this some "idiomatic Go confusion"? > In > particular it's easy for people to be misled into thinking that if a > low priority case is chosen then at that point none of the high > priority cases can be ready, but of course that is false (as the high > priority case may have become ready in the span of time between > choosing the low priority case and starting to execute the associated > statements). > Exactly! Øyvind *Enough of me for now.* > > Ian > -- 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/6e7d348e-0ed0-4320-92f7-907988ca8706n%40googlegroups.com.
