Proposal: option to lock child goroutines to same OS thread

[shelby3]

I responded in a comment to a Stackoverflow question Does runtime.LockOSThread allow child goroutines to run in same OS thread? about unavailability of this feature:

Even though it’s not currently supported, it has been proposed for a new optional capability. And I have proposed other use cases.

I became motivated to propose this here when I realized a very important style of programming that can’t be done without adding this capability.

I searched for other issue threads and the somewhat related ones found:

#4056
#21827
#12462

Seems perhaps the last one #12462 could be addressed with this proposal?

How does the community feel about this proposal? Would it likely be accepted into the mainline if someone did the work?

EDIT: please read my follow-up post, wherein I explain this really isn’t about supporting FRP, yet more fundamentally about optimal event handling (in any programming paradigm) in the UI thread and lockless concurrency design. I don’t wish for readers to misinterpret this proposal as an attempt to turn Go into Haskell (I know Go’s target audience would be turned off by that). That’s not the point.

[ianlancetaylor]

I'm not sure I understand what you are proposing. If one goroutine is locked to a thread, then how can a different goroutine be locked to the same thread? What happens if both goroutines should run simultaneously?

[aclements]

I became motivated to propose this here when I realized a very important style of programming that can’t be done without adding this capability.

I haven't read the entire zenscript thread you linked (or really much of it; it's pretty long :), but I don't understand what problem in FRP is solved by forcing multiple goroutines to run on the same OS thread. Could you summarize, perhaps? Go's use of OS threads is transparent unless you're interacting with things outside of Go that care about OS threads (e.g., things that have thread-local state). And locking multiple goroutines to the same OS thread isn't going to give you more control over their scheduling because the Go scheduler will still preempt and switch between them.

OTOH, having a mechanism to lock multiple goroutines to the same OS thread is a recipe for deadlocks. What if one of those goroutines enters a system call that blocks until some action is performed by the other goroutine locked to that thread?

[shelby3]

@ianlancetaylor, my thought was that a goroutine can be blocked on for example I/O or waiting on a message/signal in a channel (or analog that can model waiting for events). So then another goroutine in the same thread could run. goroutines are superior to Promise for modeling “logical threads”.

Perhaps this means OS calls would have to be implicitly transferred (by the runtime, not the Go code) to a different thread in that case. I haven’t thought about the internal implementation details. Very high performance, ultra low latency use cases benefit from non-blocking I/O, so in those cases you’d want to no switch to another goroutine in the same thread.

Afaics this has some analogous capabilities to an event loop in JavaScript with callbacks. It would afaics facilitate code targeting the UI thread in JavaScript via Gopher et al (and maybe also Android per #12462?) programming. Of course we’d still want to retain the capability to spawn child worker pool goroutines which don’t have the restriction.

@aclements,

what problem in FRP is solved by forcing multiple goroutines to run on the same OS thread. Could you summarize, perhaps?

1. Event handling is traditionally an imperative spaghetti. I posited that the FRP model I outlined would provide much saner separation-of-concerns that would provide the sort of improvements in clarity, reasoning, and reliability that Haskellites claim.

   Without restating those points in detail and even to separate my point from FRP entirely, when some UI code is waiting on events, we don’t want to have to write that code to be preemptively interrupted by each event listener running simultaneously on a different thread. The problem of thread safety and data races makes reasoning very difficult. We don’t need nor want multi-threading in UI code.

2. Related use case (or a generalization of the prior point) is aiding lockless concurrency design by restricting to a single-thread. This can greatly aid reasoning about shared mutable state (which is one of the justifications for the JavaScript single-threaded event model), because the opportunities for the shared state to have a race condition are more restricted since only one of the goroutines can run simultaneously. This is often quite adequate, because for example there can be multiple instances of these single-threaded concurrency constructs running simultaneously.

I haven’t studied what Gopher does. Perhaps it provides access to the JavaScript event loop separately from the concept of a goroutine. Yet I would prefer to see concurrency modeled exclusively with goroutines (or even better algebraic effects, but that’s not applicable here) because goroutines are superior to Promise. With a WASM Go target under development, hopefully we won’t be forced to use JavaScript and Promise forever.

[bcmills]

a goroutine can be blocked on for example I/O or waiting on a message/signal in a channel (or analog that can model waiting for events). So then another goroutine in the same thread could run.

That is already how the Go runtime works: when one goroutine blocks, it chooses another goroutine to run on the same thread.

The problem of thread safety and data races makes reasoning very difficult.

Eliminating threading does not eliminate concurrency bugs or aliasing bugs. Communicating by sharing memory is precarious even if you can assume that operations won't be preempted.

aiding lockless concurrency design by restricting to a single-thread

You can already restrict a variable to a single goroutine (by not passing it to other goroutines). Can you give some more concrete examples?

[shelby3]

Eliminating threading does not eliminate concurrency bugs or aliasing bugs.

Not entirely, but it can greatly facilitate reasoning and even can facilitate proving safety more easily and with more algorithmic flexibility than Rust’s lifetimes + exclusive mutable borrowing. I analyzed this in detail in issue thread 35 at the Zenscript repository. I even showed false positive cases that Rust’s checker can’t prove are safe, yet are safe. Willy-nilly preemption is often impossible to reasonable about and we punt to locking with mutexes which can’t be proven to not have deadlocks nor livelocks.

Afaik, Go can’t even prove safety at all, and punts to a runtime check, which of course isn’t safety unless you’re sure your unit tests have hit every corner of the universe.

Here I am suggesting how in general to get better safety margins easily (and also enabling easier and more optimal programming for a single UI thread with concurrency as one specific use case). Isn’t Go all about making it easier and hassle-free for programmers? What we like to refer to as a “no brainer” decision if it doesn’t have any unforeseen downsides.

Why go multi-threaded in the cases where the programmer doesn’t want it? What is the downside of providing the requested feature?

The FRP use case I referred to in the OP is a prime example of provable safety obtained with single-threading multiple logical threads. For optimal coding (least boilerplate and conflation of separate concerns) it requires continuations, i.e. goroutines. Implementing event listener code with callbacks or even Promise conflates what should be separate concerns. I explained that in more detail in the link I provided explaining why goroutines are superior to Promise. This doesn’t mean the feature request is only applicable to FRP. Rather I’m presenting it as an example of how to attain provably safe lockless code if all the continuations run in the same OS thread.

_{(Btw, having to beg for this feature is yet another reason that algebraic effects are conceptually superior to goroutines, because programmer has full control over the continuations and can decide whether to use single-threads or M:N in the handlers, although goroutines may be and likely are more performance optimized, so I’m hoping this feature makes sense for Go)}

Communicating by sharing memory is precarious even if you can assume that operations won't be preempted.

Part of the challenge is proving when sharing is not overlapping. Simply forbidding all sharing (such as everything must be copied) even when not overlapping is algorithmically inflexible, as a dual to the inflexibility of Rust which forces exclusive borrowing everywhere.

You can already restrict a variable to a single goroutine (by not passing it to other goroutines).

That doesn’t facilitate multiple logical threads with only one running at the same time. Or does it somehow that I’m not aware of?

Can you give some more concrete examples?

The asynchronous single-threaded concurrency that can be obtained with JavaScript Promises examples, except afaics without their negatives if we have the feature I requested for goroutines.

Promises are also creating logical threads with their own “stacks”, but those stacks are closures stored on the heap. They run in a single-thread. The goroutines provide a similar functionality (if they can be optionally requested to run in the same OS thread), and with a superior semantics (and also I believe more performant) than Promise as explained at the link I provided.

[aclements]

1. Event handling is traditionally an imperative spaghetti. I posited that the FRP model I outlined would provide much saner separation-of-concerns that would provide the sort of improvements in clarity, reasoning, and reliability that Haskellites claim.

Without restating those points in detail and even to separate my point from FRP entirely, when some UI code is waiting on events, we don’t want to have to write that code to be preemptively interrupted by each event listener running simultaneously on a different thread. The problem of thread safety and data races makes reasoning very difficult. We don’t need nor want multi-threading in UI code.

Right, I understand the differences between event-driven programming and FRP. What I don't understand is what this has to do with locking multiple goroutines to the same OS thread. This doesn't solve anything about thread safety and data races and more than, say, running a multi-threaded program on a single core CPU does. The goroutines can still context switch at any point, so you still need to protect thread safety.

2. Related use case (or a generalization of the prior point) is aiding lockless concurrency design by restricting to a single-thread. This can greatly aid reasoning about shared mutable state (which is one of the justifications for the JavaScript single-threaded event model), because the opportunities for the shared state to have a race condition are more restricted since only one of the goroutines can run simultaneously. This is often quite adequate, because for example there can be multiple instances of these single-threaded concurrency constructs running simultaneously.

It doesn't help here either, again because goroutines can context switch at any time. The only "advantage" of restricting to a single OS thread is that you could use non-atomic load and store operations, but even then you need atomics for read-modify-write operations, such as adding to a shared variable.

Here I am suggesting how in general to get better safety margins easily

That would obviously be great, but locking multiple goroutines to the same OS thread in no way achieves this.

[shelby3]

The goroutines can still context switch at any point

Oh I didn’t contemplate that in the single-threaded case. I thought they only context switch when blocked or non-deterministically to balance load/starvation. Why would they context switch for reason other than blocking when confined to switching within the same OS thread? Would they switch at non-deterministic points to prevent starvation of the other goroutines in the same OS thread?

So in the single-threaded case, I suppose I’m expecting that the programmer is given manual control over starvation and the goroutines must only block deterministically.

I suppose I grok the argument for benefit of not giving the programmer manual control in the M:N case, analogous to arguments that can be made about letting the runtime handle memory GC.

That would obviously be great, but locking multiple goroutines to the same OS thread in no way achieves this.

Afaics it would achieve it, if we can (even optionally) have deterministic (i.e. compile-time) reasoning about context switch points in the single OS thread case.

[ianlancetaylor]

Frankly it sounds like you are looking for a different language.

You could write what you want in Go by having a goroutine lock itself to a thread and then manage work queue, where the functions in the work queue decide when they want to yield. But I really can't see changing Go to work in that model natively.

[shelby3]

Frankly it sounds like you are looking for a different language.

Maybe so, but could someone please explain why you want to handicap the use case of Go for UI programming?

There’s apparently been significant demand for transpiling Go to the browser for example, such that there’s already three such transpilers and apparently one or two WASM compilers in development.

You have this CSP goroutine model that could be much better than using Promise style cruft which conflates control structure with functions, and all you need to do is restrict context switching to blocking when the programmer has requested it (and requested the child goroutines run in the same OS thread).

Also afaics the single-threaded model I proposed with better invariants for lockless safety, could also potentially be employed in general cases, not just UI. Where the benefits from improved invariants outweighs the M:N automagic in the runtime for those cases. The programmer could mix-and-match runtime M:N and single-threaded paradigms as fitness dictates.

You could write what you want in Go by having a goroutine lock itself to a thread and then manage work queue, where the functions in the work queue decide when they want to yield.

Isn’t this essentially simulating promises and the lack of fined-grained control over the continuation (which afaics only the plurality of goroutines can provide unless we essentially perform whole program transformation to a switch block for emulating continuations, which would require a transpiler and probably be slow and highly unoptimized) which causes the cruft and conflation that makes coding horrific. I thought you want Go to be elegant with code that isn’t unnecessarily convoluted just to work around lack of a necessary language feature?

[aclements]

Why would they context switch for reason other than blocking when confined to switching within the same OS thread? Would they switch at non-deterministic points to prevent starvation of the other goroutines in the same OS thread?

This can happen for various reasons. The runtime preempts goroutines after 10--20ms just to maintain fairness and to eliminate some deadlock situations (for example, a goroutine looping on some shared state, waiting for another goroutine to change it; not that a busy wait like that is recommended). Preemption can also happen because of the GC, for example during STW or when the GC needs to scan a goroutine's stack.

So in the single-threaded case, I suppose I’m expecting that the programmer is given manual control over starvation and the goroutines must only block deterministically.

In a sense, you already have this through channels. The fact that the goroutines may run on different OS threads is largely irrelevant (and the Go runtime will try to keep them on the same thread). In fact, I've done explicit co-routine-like scheduling in Go for the purposes of systematic concurrent algorithm model checking and it works quite well: https://github.com/aclements/go-misc/blob/master/go-weave/weave/weave.go. You still get the separate stacks and control flow of each goroutine. You just have to manage the channel blocking so that only one goroutine is unblocked at a time, which isn't very hard to do if you're already reasoning about all blocking behavior.

[ianlancetaylor]

Maybe so, but could someone please explain why you want to handicap the use case of Go for UI programming?

I don't, but I also do not understand why the feature you are asking for is required for UI programming. To me it sounds like you are asking for greater complexity--as you can from your reaction to my suggestion for how you could implement it today. Any system that requires goroutines to explicitly yield is more complex and harder to program than the current system.

Also afaics the single-threaded model I proposed with better invariants for lockless safety, could also potentially be employed in general cases, not just UI. Where the benefits from improved invariants outweighs the M:N automagic in the runtime for those cases. The programmer could mix-and-match runtime M:N and single-threaded paradigms as fitness dictates.

Speaking personally, I do not agree. I do not want programmers to have to reason about lockless safety. Experience shows clearly that most programmers get it wrong. I want programmers to use simple building blocks that are clearly correct, and I want those building blocks to be fast enough to nobody avoids them. (You may argue that explicit yielding makes lockless safety easy, but it requires that you carefully avoid yielding while holding an implicit lock, and that is hard to prove as your program changes over time.)

I think we need to take a big step back and understand the problem you want to solve, rather than framing it in terms of a solution. The best I can figure out at the moment is that you want to be able to write safe lockless concurrent programming. Go lets you do that using channels--of course, that works because channels have implicit locks. To be able to write concurrent code without even implicit locks is not a goal of Go; that is much more in Rust's bailiwick.

[shelby3]

@aclements,

This can happen for various reasons. The runtime preempts goroutines after 10--20ms just to maintain fairness and to eliminate some deadlock situations (for example, a goroutine looping on some shared state, waiting for another goroutine to change it; not that a busy wait like that is recommended).

Ah yes makes sense, but if there’s no other way to achieve what I think is necessary, I would argue the programmer should be allowed to turn off that heuristic if his use case benefits more than the tradeoff of not having that heuristic. Yet see below…

Preemption can also happen because of the GC, for example during STW or when the GC needs to scan a goroutine's stack.

But afaik that preemption doesn’t have any impact because it’s not preempting with another goroutine. The resumption could in theory continue the goroutine that was preempted. Or am I missing something?

In a sense, you already have this through channels. The fact that the goroutines may run on different OS threads is largely irrelevant (and the Go runtime will try to keep them on the same thread). In fact, I've done explicit co-routine-like scheduling in Go for the purposes of systematic concurrent algorithm model checking and it works quite well: https://github.com/aclements/go-misc/blob/master/go-weave/weave/weave.go. You still get the separate stacks and control flow of each goroutine. You just have to manage the channel blocking so that only one goroutine is unblocked at a time, which isn't very hard to do if you're already reasoning about all blocking behavior.

Okay yeah I see now that if the programmer will explicitly control the blocking of all goroutines he wishes to run only one at a time, then whether they run in different OS threads or not is irrelevant.

But here we’re forcing into userland or library code what could and arguably should be in the runtime.

And there could be race conditions because for example when we want what is essentially a select and we want the goroutines to block on I/O, channels and what have you, then the goroutines may be blocked into non-userland code (e.g. for I/O) where our userland blocking scaffolding can’t reach. So then we may have more than one goroutine unblock simultaneously and our blocking scaffolding then has a race condition. I’m just quickly visualizing this in my head, so please do correct me if you find a mistake in my reasoning.

---

@ianlancetaylor,

I don't, but I also do not understand why the feature you are asking for is required for UI programming.

Because in event handling we have to deal with concurrency because events fire asynchronously. And thus either we need to use some callback model, which conflates control structure with functions, and creates an imperative mess of spaghetti which also is hard to reason about even though it runs in single-thread. Or we can more elegantly use continuations (i.e. goroutines) which unconflate and then I and others can build elegant paradigms on top of that such as FRP which provide complete safety.

In either case, I argue we need protection from willy-nilly preemption which serves no purpose in UI programming and only makes safety much more difficult to achieve.

Any system that requires goroutines to explicitly yield is more complex and harder to program than the current system.

Use cases dictate analysis. In the M:N use cases, I agree with you as I mentioned by “grok” upthread. But afaics the UI use case can not be nailed with the same hammer. Go was clearly first prioritized around server programming. We may have to adjust our thinking a bit. Perhaps I am totally wrong though. I am eager to read the replies and continue absorbing new information.

Speaking personally, I do not agree. I do not want programmers to have to reason about lockless safety. Experience shows clearly that most programmers get it wrong. I want programmers to use simple building blocks that are clearly correct,

Which is precisely what I propose FRP could accomplish in the event handling case. In any case, I fail to understand how throwing promisicrufication or willy-nilly preemption at UI coding will make it easier than restricting to a wider safety margin of single-threaded continuations. But I’m not an expert actually on this, so perhaps I’ve overlooked something?

You may argue that explicit yielding makes lockless safety easy

Not necessary. I can just argue it is less worse than the alternative?

The best I can figure out at the moment is that you want to be able to write safe lockless concurrent programming. Go lets you do that using channels--of course, that works because channels have implicit locks.

I think I may have shown above in my response to @aclements, that scaffolding can create races. And also I presume it’s a lot cruft where I posit it could be elegantly handled by the runtime.

To be able to write concurrent code without even implicit locks is not a goal of Go; that is much more in Rust's bailiwick.

Afaics that you’re placing my proposal in a taxonomy it doesn’t belong. I am asking for explicit opportunities for context switching on explicit blocking (no locks). Rust assumes preemption every where, and thus must prove exclusive borrowing of objects everywhere. That is very onerous and inflexible. Whereas, I am coaxing out the easy safety by setting some simple non-obtrusive invariants that fit well in some use cases.

There’s appears to be some cognitive dissonance (maybe on both of us to some extent). I hope we can find a way to communicate our respective understandings and discover our misunderstandings.

[ianlancetaylor]

I am asking for explicit opportunities for context switching on explicit blocking (no locks).

Clearly you can do that by running code in a single goroutine. So my current understanding is that you want goroutines that only switch to other goroutines on some sort of explicit yield. In the absence of an explicit yield, you want that goroutine to continue running. In particular, even if the goroutine blocks, say on a network call, you do not want other goroutines to run.

If that understanding is correct, then presumably this only applies to some set of goroutines. It can't apply to goroutines produced by the Go runtime itself, such as for the garbage collector. So there needs to be some way to define a set of goroutines.

Someone reading or modifying your code has to have a clear understanding of which code can be executed by goroutines in this special set. Presumably the program will be written with the understanding that some data can only be accessed by a single goroutine at a time, because other code somewhere else ensures that all goroutines that access that data are in this special set.

To me that all seems complex. But I may well misunderstand the model you want.

Suppose instead that every time you start a task, whatever that means in your system, you acquire a lock, and every time you explicitly yield, you release the lock. To me that seems explicit and clear. The cooperation is enforced by the explicit locks, rather than by the implicit scheduling locks of the approach described above.