Go isn’t a run-to-completion task model. It’s almost fully preemptible.
-
-
He was talking about cilk in the tweet I replied to...
1 reply 0 retweets 0 likes -
I agree that Cilk certainly has benefits over 1:1—we have a Cilk clone called Rayon in Rust that is widely used (in Firefox for parallel CSS styling, for example). My comments are about threads that do I/O.
1 reply 0 retweets 0 likes -
Yeah, rayon is fantastic. https://dave.cheney.net/2014/06/07/five-things-that-make-go-fast … says that go is NOT preemptive. Has that changed since? I recall that it is preemptive, but my memory is real bad. I'll go through the code soon.
1 reply 0 retweets 0 likes -
Like other M:N threading systems, go threads are cooperative at one level (from the perspective of the implementation of the thread system) but preemptive at another level (from the perspective of the go programmer).
1 reply 0 retweets 0 likes -
Are struct G runqueues synchronized? I'm trying to figure out where real preemption is killed. From the programming API perspective, they don't list blocking points being inserted into tight loops without allocation. That would break the preemptive behavior abstraction, right?
2 replies 0 retweets 0 likes -
Right, you can starve other threads with a tight loop that doesn't allocate/do IO/etc. But that's a failure of fairness by the scheduler, not cooperative multi-tasking.
1 reply 0 retweets 0 likes -
It indicates a lack of preemption in the programming model. I would argue that due to this, go is not a preemptive environment, even at the programmer level. At best, it provides a leaky abstraction. Is this wrong?
1 reply 0 retweets 0 likes -
I think that's wrong wrt how these terms are usually defined. Go programmers don't explicitly `yield` to other threads, as they would in a cooperative system (ie, classic macs). Instead your thread gets preempted without you doing anything. The scheduler is just sometimes unfair.
1 reply 0 retweets 1 like -
Interesting perspective, thanks. I would personally think of it more as the cooperative yields just exist in library functions, so that you don't have to call them. By your definition, I believe openmp is preemptive as it defines scheduling points in language/library ops.
3 replies 0 retweets 0 likes
You can starve threads in Go if you have long-running loops. IIRC preemption points are at function boundaries only.
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.