Friday, February 22, 2013

Go, data races and combining

Hi,

I continue my work on speeding up Go language. The next major release will feature faster parallel garbage collector, goroutine blocking profiler (enabled with -blockprofile flag) and a lot of other yummy features. Last but not least -- builtin data race detector. Yay! Just add -race flag.

The race detector is based on our ThreadSanitizer technology, which is initially developed for C/C++. Now that both C and C++ standards have multithreading support, data races officially banned as "undefined behavior". You can read my essay on data race here.

If you are subscribed to this blog, you are probably interested in synchronization and concurrency stuff. It's not that I am writing a lot lately, but here is at least something new -- Combiner/Aggregator Synchronization Primitive.

Best

5 comments:

  1. Combiner/Aggregator seems to share some conceptual underpinnings with Oyama's technique (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.159.183) and more recent work by Fatouro et al (http://dx.doi.org/10.1145/2145816.2145849)

    Regards, -Dave

    ReplyDelete
  2. Thanks for the links!
    I am sure there must be some analogous work, because the idea is somewhat obvious. But I am eager to see whether they do something differently than others.

    ReplyDelete
  3. Small Business Phone Service have come a long way in a relatively short period of time. No longer do you have to pay a lot of money to install cumbersome, expensive systems - and yet, you have access to more flexibility, more features, and better sound quality than ever.

    ReplyDelete
  4. Hello Dmitry, thanks for the yesterdays wonderful lection on the Go internals!


    Yesterday evening, an interesting question was raise that may worth a bit more attention than it got during the short meeting timespan. It was not me who raised it, but after the lecture it made me think a lot on the question: why indeed the goroutines are not (at least optionally) kernel-scheduled?

    Why not use and/or add the OS-available means for the fiber switching? There is the WinAPI support for the Fibers on Windows; I don't recall any complete fiber support on Linux, but, provided the Google resources, it probably could've been added in a way usable not just by Go.

    But this potentially would make it possible to implement much better goroutine scheduling, cpu affinity (even up to increasing the chances of a goroutine to be re-executed on a particular CPU, not just in the particular thread), some insane stuff like smart handling of the syscall blocking (I can even imagine that a `read()` attempt may switch the goroutine if the data is going to be read from the physical file, but gets back to the same goroutine immediately if the data is available in the disk cache)...

    I believe, the primary answer will be that every such feature needs a person who pushes it and writes the code; but I am mostly interested if there are any ideological/political obstacles that definitely block it from happen someday.

    Hope this thought doesn't sound too nooby and theoretical, and thanks in advance if you find my question worths your time to answer it.

    ReplyDelete
  5. Please post this question to golang-nuts@

    ReplyDelete