Hmm… Not sure about repetitavely saying that specific data should not be accessed concurrently. Better may be to say that nothing (generally) should be accessed concurrently; that concurrency is accessed by a few special mechanisms that hide the concurrency behind a reasoned, reliable facade of sequential operation. This is already said in several ways so maybe rather than saying it for each data item and each API element, we should encourage self-study in the literature.
Perhaps there should be a “The Go Mindset” document for background on the intellectual heritage behind Go’s concepts in concurrency. The history is essential and it is sobering to think that not everyone is intimately familiar with it. When I read the Go documentation, several computer science heroes and their original papers are on my mind: C. A. R. Hoare (“Tony Hoare”), inventor of Quicksort and essential to Go, the expositor of Communicating Sequential Processes, with collaboration by Edsger Dijkstra: Communicating Sequential Processes (this is THE paper of all papers) http://spinroot.com/courses/summer/Papers/hoare_1978.pdf A Model for Communicating Sequential Processes http://ro.uow.edu.au/cgi/viewcontent.cgi?article=1013&context=compsciwp Per Brinch Hansen wrote an early book (1977), “The Architecture of Concurrent Programs” that was important to me as a tutor. It teaches the design complex concurrent systems as a loosely coupled ensemble of sequential components connected safely by a minimal rigorous infrastructure of channels, send, receive, and select. Architecture of Concurrent Programs (Google Book Search <https://books.google.com/books?id=0KVQAAAAMAAJ&q=The+Architecture+of+Concurrent+Programs&dq=The+Architecture+of+Concurrent+Programs&hl=en&sa=X&ved=0ahUKEwiJ08yIs6XNAhUHfVIKHQPhAgAQ6AEIHjAA>) Per Brinch Hansen The Origin of Concurrent Programming (Google Book Search <https://books.google.com/books?id=c__lBwAAQBAJ&pg=PA3&dq=The+Origin+of+Concurrent+Programming&hl=en&sa=X&ved=0ahUKEwiCkv3Ps6XNAhVEXlIKHeDKBRUQ6AEIHjAA#v=onepage&q=The%20Origin%20of%20Concurrent%20Programming&f=false>) RECENT! Per Brinch Hansen These are the fundamental technical preparation to approach Go’s concurrency concepts. It is helpful to read them not only for the insights but also for the confusions. (Things murky to brilliant people are often the “X” in a treasure map, with Euclid’s fifth postulate being the ultimate example.) Another great "background for Go” text is a book by a friend of mine, Dr. Fred Brooks of UNC and formerly of IBM. He is famously the author of The Mythical Man Month but his magnum opus for me is the book, The Design of Design: Essays from a Computer Scientist. There is no better book on design—or rather, the science of meta design—in the world. The closest rivals would be books on city design and urban architecture. The Design of Design: Essays from a Computer Scientist (Google Book Search <https://books.google.com/books?id=0qG4TQi-e-4C&printsec=frontcover&dq=fred+brooks+design&hl=en&sa=X&ved=0ahUKEwjRjK2RtaXNAhVUMFIKHRN9BzYQ6AEIHjAA#v=onepage&q=fred%20brooks%20design&f=false>) Frederick P. Brooks Jr. One lesson from Dr. Brooks is the notion that “total design” leads to efficient solutions but rigid systems not well suited to change while “loose design” anticipates change, extension, and revision. (I am paraphrasing here but the ideas are his.) Examples of loose design might be LEGO with modular parts or in the Go context, channels and garbage collection which together make “send and forget” possible, the pair of which makes an arbitrary graph of independent communicating processes workable and in fact, generally desirable over a carefully conceived asynchronous program, such as a cleverly tuned game engine. Perhaps a list of references and suggestions of lessons to be learned would be good as a link from the Go website. Michael > On Jun 13, 2016, at 8:43 AM, Sam Whited <s...@samwhited.com> wrote: > > On Mon, Jun 13, 2016 at 10:18 AM, roger peppe <rogpe...@gmail.com> wrote: >> No Go type should be assumed to be safe for concurrent use unless explicitly >> documented otherwise (or obviously safe, for some definition of "obvious"). > > I think that's what I said? Either way it seems like there's no harm > in being explicit. > > —Sam > > -- > Sam Whited > pub 4096R/54083AE104EA7AD3 > https://blog.samwhited.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. > For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
