Google I/O 2012 - Go Concurrency Patterns
Вставка
- Опубліковано 17 чер 2024
- Rob Pike
Concurrency is the key to designing high performance network services. Go's concurrency primitives (goroutines and channels) provide a simple and efficient means of expressing concurrent execution. In this talk we see how tricky concurrency problems can be solved gracefully with simple Go code.
For all I/O 2012 sessions, go to developers.google.com/io/ - Наука та технологія
Register to save your spot for Google I/O✨➡ goo.gle/io24-yt
Rob's clarity in these talks is next level. Each one I watch gets me more excited about learning Go.
I am a teacher myself and I can see how much work was put in the preparation for this talk. Few weeks probably for 40 minutes talk.
Though having seen these patterns when reading open source code before, it's still very helpful to watch this video. Thanks!
I'm relatively new to programming and was trying to get the hang of multithreading in Go. This video helped a lot. Thank you.
By now, you are probably programming expert.
Are you a super saiyan programmer bro
Go is growing on me more and more. In fact, I'm starting to love it.
@John Markovich Well I do still love it :D
Rob really can explain
Ker-Kling that's the penny dropping for me on channels in Go... Amazing talk
The best presentation for Go Concurrency.
Still true. I'm learning Go now, I've watched a lot of videos and read books and this is the best.
Great talk, many thanks for publishing it
Very clear and concise, right timing too.
"To make the boring less interesting" what a great sentence.
You're easily impressed
23:40 when you click on "Run" again, just to double-check whether you seeded your PRNG with a random value. But you didn't! XD THANK YOU FOR THE TALK!
Amazing language handling the concurrency
Superb explanation!
Thank you for such a great presentation! The concurrence examples were exactly what I was looking for, and convinced me to start learning Go today.
Might you consider using concise file reading and parsing like in AWK? Thanks.
loved the last question: "if my routine is deadlocked, will it stay like that?", i mean, he gave fairly good number of examples of how timeout such things.
The question did state "and I don't have a timeout". Another asker followed up later with the same question. What happens if a writer writes to a channel and no one ever reads from it.
From what I can gather in Go is that you simply "Don't let it happen". If you need to make a dynamic decision on a channel, you need to have the signal passed across, or use a buffered channel.
Thanks for this Rob
Wonderful talk as is the language.
A good talk, i'm definitely going to learn Go.
Also, about Heroku Waza talk that Rob mentioned, it's not out yet apparently (after 6 months).
what an excellent man
Is there any one watching this video in 2021 just like me
Hi, I'm from the future...
2024, still a great lecture
2024
Awesome presentation!
A remarkable talk
Very interesting. Used it in my concurrency class.
Highly recommend to watch this video after you read all offical tour for deeper understanding.
I agree. This is what I felt was "missing" from the tour
great presentation
this is a great talk. very inspiring.
great video
Awesome Video!
A switch isn't made for communication (channels), switch just does value comparison. It is not posible to use use a channel get (myInt :=
Though go is a static language, it can be so powerful that it has elegant grammar and better concurrency capability that make us write less yet robust code
Less code means more black box magic and opinionated design. It’s painful
I
amazing presentation
great presentation.
@25:23 This seems like an anti pattern, because both go routines (the parent and the child) play the role of sender and receiver on the quit channel. Seems to me, you generally want one go routine to only send, and the other to only receive (on the same channel). In this case, seems to make the most sense that the parent go routine is the sender (on the quit channel) and the child only receives (again, on quit). To make the parent block on cleanup returning, you'd have a third channel: done_cleaning_up, which (in addition to c, the primary result channel) gets returned by boring. I know that's 50% more channels than the design shown, but I feel that more channels is preferable vs. overloading quit.
If we could change the language slightly, another way to make this nicer is if the receiver had the ability to close a channel (Go only allows the sender to do this), because then, instead of using quit to signal from the parent to the child that no more values are wanted via c, the parent simply closes c, and the send in the child would fail.
I hope google goes with go (golang) as the new official language for android development, it will be the most assertive choice. This will be the big “Nextstep” for android ;)
it would be great and cool!
I hope google realizes their err and goes back to Java. The most readable of the bunch. Kotlin is a notch more repulsive than go, but they’re both terrible
I think current would be a better name for channel, but maybe it's just me ;)
Great!
34:55 Claps!!
Slides at talks.golang.org/2012/concurrency.slide
Hey guys I heard you like channels so I put a channel in your channel
yo dawg
damn, 6 years ago..
8.5 years ago
I was trying to follow this along on my local, an interesting finding at 18:06 , in the fanIn function when you spawn two anonymous goroutines, if you don't use for loop around c
@31:56 The loop in the second half of this example is funny, because there is a magical number in there (i < 3), which you have to remember to update if you add something like Shopping. I think in other languages, you would join all the threads (or in this case, go routines). Unfortunately, go routines have no handle on which to join.
Yeah it's a trick. Formally you need a wait group and a new goroutine to wait all the searching goroutine to finish, and then close the channel. And in main goroutine, you can use a for-range on the channel. The lecturer just tried to avoid the using of waitgroup 'cause it's gonna be a distraction.
@@kevinchou9155 No, actually all the search functions have all the same signature, you could collect them in a slice and spawn them off as Go-routines in a for-loop. Then the second for-loop iterates the same number of times as the length of the slice. (i.e the same number as the number of search functions). You don't have to close a channel in order for it to be garbage collected, as soon as a channel goes out of scope and is not referenced it will get garbage collected. It's clearly stated in the language documentation. There is no need for a wait-group.
If you need to signal a consumer that the producer is done, then you can do it by closing a channel,- or if you iterate over a channel with a for-loop, ( for element := range channel { ...} ), you need to close the channel in order to end the for-loop.
Nice
It is out on vimeo now
Maybe on the surface. If you want to see the difference, time running 100,000 async calls. ;)
Re 49:20 -- Instead of nesting, it seems like you could just use a switch statement, I think...
good
WoW Moment at 28:16!!
shit flew above my head!
28:50 "and some ads" Rob is humorous
سبانم٧اغزعخع٦لنع٦تت٥ل٥فد٤دثذثذث، ثصظضاخككحةك٠ةجةةكنبفيقتيثس🎉
Lugina e Ujqërve Pjesa VI 1
😢❤🥝😊الله
مشاهدة
In the fanIn part, isn't it just unnecessary to make some sort of separate proxy function for them when we can just modify the boring function to take in more than one param and function just like a multiplexer, while the fmt.Println() function prints whatever value it gets first from the boring function
6:12 "These are going to be really boring programs, but they're going to use concurrency to make the boring a little less interesting." :D
So regardless of whether I use the fanIn function with two goroutines or the select statement (and copying the code straight from a copy of the slides) -- if I run the sleep with 'rand.Intn(1e3)' I always see Joe / Ann print in lockstep, and if I run it with 'rand.Intn(1e2)' I always see a pattern of 0,0,1,1,2,2,3,4,3,5 (sometimes Joe gets to 5, sometimes Ann does). I've ran it numerous times and never seen a deviation from this. Unless I'm mistaken -- this isn't the expected behavior. What's going on here?
+AnirudhC Nvm - I see the rand is deterministic, very interesting
+zubie7a Yup that was the issue!
@@zerosandones701 tour.golang.org/basics/1
@@zerosandones701may be "Note: The environment in which these programs are executed is deterministic, so each time you run the example program rand.Intn will return the same number.
(To see a different number, seed the number generator; see rand.Seed. Time is constant in the playground, so you will need to use something else as the seed.)" from tour.golang.org/basics/1
Correct me if I'm wrong, but doesn't the select statement do exactly what he's trying to do with fan-in?
If you are talking about the fanIn with two goroutines vs with only one: he said it is equivalent, just a different way to express the same idea.
p.s.: if you meant that the fanIn function is not necessary, simply inline it, it could be done for both too, I think.
This talk scares me about concurrency.
08:40 Goroutines
10:29 Channels
The answer to the last qn should have been "Now why would you do something like that".
Source code link: talks.golang.org/2012/concurrency/support
Thanks!
Could somebody tell me how can I get the source code in this presentation? Thx a lot
I think I know how they've come up with golang logo :)
how i dont get it lol
Wow! :P I never looked at it that way until now. Pure discrimination! :P
21:21 :: recieved ? from c2
Can I please get the code snippets and slides for this?
Rob expands on his comment at the end of this about blocking goroutines, that won't return, being garbage collected, saying the goroutines do need to return, otherwise they will be a leak. time.After solves this by using a buffered channel, so even if the channel is not being read, it will return, and if there's no other reference to the channel after time.After returns, the channel is garbage collected.
groups.google.com/forum/m/#!topic/golang-nuts/bfuwmhbZHYw/discussion
The answer to the first question was unclear. So the indeterminism of go routines cannot be mocked and you just mock the service being called ?
Could someone explain through the Daisy Chain example at 26:27? Thanks!
The main idea is about creating 10000 blocked goroutines, each copies value from the right channel to the left channel. The creation sequence is from the last channel(leftmost) to the first one(rightmost). In each creation procedure, after finished creating the goroutine, the left channel is no longer needed, and the right channel becomes the left channel we will need in the next iteration, so we made the right become the left for next iteration during which a new right will be freshly made. After the creation completes, all 10000 goroutine are blocked, since no value is sent through the first(rightmost) channel. Then we sent a value, and the value get passed through all the channels and goroutines. The key point is that the whole procedure is really fast with go considering the total numbers of the goroutines. So goroutine is realy light-weighted.
Hi from 2024!
I met some difficulties in understanding of this code part, so I decided to rewrite one a little bit and add comments for better understanding. Here it its:
func main() {
n := 100000
// In Rob's code `right` variable has been initialized as `right := leftmost`
// However, it rewrites every time in for-loop below, so we don't have to initialize `right` here (what a pan!)
// But we have to keep visibility of this variable within the main function because we have to call it after for-loop
// The clearest way for us is to declare `right` variable here without initialization
var right chan int
leftmost := make(chan int)
left := leftmost
// I spent a lot of time to get the one simple point
// We're building a chains here from left to right
// Not from right to left as you can see in the picture with Gophers
// Don't be fooled by arrows direction
for i := 0; i < n; i++ {
right = make(chan int)
go f(left, right)
left = right
}
// I rewrite this code a little bit
// It's clearer for me than the Rob's code
// Just put a 0 to the rightmost channel to start the whole process
go func() {
right
The slides link
talks.golang.org/2012/concurrency.slide#1
Looks cool, but I still don't get it - how are channels all that much different from threading ? What's the advantage over threads?
+Alex George tleyden.github.io/blog/2014/10/30/goroutines-vs-threads/
Alex George All concurrency implementation problems arise from threads accessing shared memory at the same time. Go takes a different approach by passing around memory to channels therefore providing implicit locking in a sense.
Goroutines are lighter than threads.
where is boring func in FanIn program,give me a clear program to understand.pls tis a wonderful in golang
@19:32 I do not see the point of these wait channels. If you want to alternate between the two original channels, don't be using fanIn to mix things up in the first place!
The daisy chain is confusing. how its giving 100001.
Otherwise awesome tutorial.
Here's the URL: rspace googlecode com/hg/slide/concur.html#title-slide
So, where's the code?
This reminds me of fork() and exec() calls to UNIX.
Not sure did watch it yet.
The Talk is posted (after a year)
blog.golang.org/2013/01/concurrency-is-not-parallelism.html
Where can I find the ppt of it?
erlang without erlang
FYI: The example here ua-cam.com/video/f6kdp27TYZs/v-deo.html does not work, runs forever. Had to refactor to use this: timeChannel := time.After(1 * time.Second). Go version: 1.14
Or a local problem time.After(900 * time.Millisecond), works
Is there any one watching this video in 2024 just like me
I think you better do what you have all the characteristics of all programming languages only it is activated and enable des modes
because by eliminating pointer index it increases security but loses dynamic processes ingenious little suspect. better have all the features including haskel but the default is to show and recommend, is concerned activate other types of programming to be even more popular and more free ... !!!
+babu OO creo que lo mejor es hacer lo que tenga todas las características de todos los lenguajes de programación solo que se activa y se des activa las modalidades
porque al eliminar los el indice de puntero aumenta la seguridad pero pierde dinamismo de procesos ingeniosos poco sospechados. mejor que tenga todas la características incluyendo haskel pero el por defecto es la que muestran y recomiendan, es cuestión activar las otras modalidades de programacion para que sea mas popular todavia y mas libre...!!!
This video confused the hell out of me. So many assumptions and skipping steps. I’m left with at least an order of magnitude more questions than when I came in.
我是搞Java的英语贼差竟然能听懂，哈哈哈
ur url is broked dood
looks like .net async
到此一游
this is a c++ modified
its more like c modified.
Andrei Chikatilo?
is Go mostly dead now?
Nope, its still super popular. And its popularity is still going up. It jumped from 54th to 13th in a year on the TIOBE index
lol, every single startup that you can find anywhere in europe and us are using go if not node.js . It's really popular for backend related tasks & systems programming. Because it's simple to read yet has all the tools to express something really complex.
So boring...
Try Go
// You can edit this code!
// Click here and start typing.
package main
import "fmt"
func main() {
fmt.Println("Hello, world")
}
Same shit in Python : print 'Hello, world'
yeah thanks ill stick with python
Now try doing the channels example in Python
+koda kitty most of them would be trivial to do with asyncio
If you are judging a whole language based on hello world you are a idiot.
also have fun with GIL
Sorry, but C# and Java are better
Go is a lot faster. By a very large margin.
Go is a lower level language which actually requires you to know programming, if you want to do stuff.
C# and Java is high level programming which compiles as ugly buggy crap.
saying c# and java compile into "buggy crap" is pretty ignorant. You would be hard pressed to find an issue caused by compiling in c# or java. The issue most people have is with the garbage collection (go is also garbage collected by the way) being slow and the fact that memory management is mostly abstracted away.
As always though, a language is just a tool, and no one tool is universally the best. There are use cases where using c# (mainly for the .net stuff) or java is better than using go.
[___ ] compare code generated by go and by Java. if you don't believe me, look what Linus Tordsvalds says.
There is the perfect language. And its name is Haskell. This language has an almost human AI and it writes code by itself. But the Dark Government is trying hard to keep this language in secret.
waitForIt = make(chan bool) Shared between all messages(struct), so all goroutines will wait for bool message from "waiForIt chan" after finishing its own tasks. Then if the main function sends a bool to the shared "waiForIt" channel, which goroutine will get the bool first? it still could keep the sequence in order?