Google's new "Go" language [LWN.net]

Google's new "Go" language

Posted Nov 12, 2009 2:44 UTC (Thu) by cmccabe (guest, #60281)
In reply to: Google's new "Go" language by wahern
Parent article: Google's new "Go" language

> Native thread implementations everywhere incur several hundred kilobytes,
> minimum, per stack, usually much more.

The in-kernel native thread implementation only takes about 4 kilobytes per thread. It is pthreads that determines your userspace thread stack size.

In the past, Linux didn't really support massive numbers of native threads very well. That has improved over the years with NPTL and better scheduler algorithms. The idea that native threads don't scale is a decade out of date. Nowadays, native threads have a lot of advantages-- they are visible to top, renice, and other UNIX utilities; they can be migrated between CPUs effectively by the kernel; and one thread doing I/O does not block other unrelated threads.

Anyway, I'm sure Go could be adapted to use native threads if someone spent some time on it.

> At the very least, channels--which Pike has used before in Alef and
> Limbo--and the segmented stack are really cool.
>
> The segmented stack solves the issue that has plagued threading (both
> user and kernel scheduled; and in C, Java, et al) and led so many
> people to use event-oriented callback models (myself included), or to
> use interruptible scripting languages like Lua.

The coroutine concept is interesting. Event-driven programming is definitely the way forward for massively multithreaded apps.

(Log in to post comments)

Google's new "Go" language

Posted Nov 14, 2009 18:23 UTC (Sat) by engla (guest, #47454) [Link]

Go already uses native threads, and already in an awesome way.

goroutines are "multiplexed" to one or more native threads. Start two goroutines, they will run, share a thread, then one of them locks on I/O. Go's runtime will put the other goroutine on a new thread to let it continue run!

Right now, threads are only used for avoiding blocking I/O in this way by default, however you can tell it to use more threads with GOMAXPROCS=N. Go code compiled with gccgo uses 1 goroutine = 1 pthread at the moment, but this should change.

Google's new "Go" language

Posted Nov 17, 2009 2:23 UTC (Tue) by cmccabe (guest, #60281) [Link]

> Start two goroutines, they will run, share a thread, then one of them
> locks on I/O. Go's runtime will put the other goroutine on a new
> thread to let it continue run!

Green threads just seem to reinvent stuff that is better done at the kernel level. For example, recent iterations of the Linux scheduler have tried to penalize threads that do a lot of computation, and push up the priority of threads that do a lot of I/O. This is supposed to make interactive performance feel quicker.

But with green threads, the kernel thread is not the "real" thread-- we will end up de-prioritizing something completely random. Kernel threads become just a set of identical slots for the "real" go threads to be fitted into. So we basically have to outsource all of the scheduler to userspace. Any volunteers for rewriting the scheduler in userspace? Don't forget to keep the two schedulers in sync, and make sure they don't work at cross-purposes...

Of course there's a lot of other complications. gettid() and renice() become virtually useless. strace and top are pretty iffy too. Anyway. You get the picture. Userspace threads just seem icky. Kind of like handling device interrupts in userspace. Sure, you can sort of get it working-- but there has to be a better way.

Anyway. Maybe once I get a chance to try out GOMAXPROCS I'll change my mind. For now, I'm not so sure about this particular feature.

Colin