Thread by @copyconstruct

First up in my @qconnewyork track - @kavya719 on lock performance!!

This talk on lock internals and performance characteristics is going to be incredible.

The Go runtime uses locks extensively (as does your memory allocator) sometimes to the detriment of performance.

The compiler and processor reorder instructions. It helps to know the rules. @kavya719 at @qconnewyork

The LOCK instruction precisely in x86 is what powers the lock implementation in most programming languages.

OMG - this talk is indescribably good! 😍

A simplified implementation of the spin lock, used extensively all throughout the Linux kernel.

And what’s the cost of an atomic operation. @kavya719 at @qconnewyork

Kernel managed wait queues — the implementation of futexes in Linux.

My tweets do complete injustice to this talk. It’s absolutely incredible! @kavya719 at @qconnewyork

The cost of a futex in both the contended and the uncontended case.

Hybrid futexes are an improvement on futexes. @kavya719 at @qconnewyork

Next up - how does a language with userspace threads like Go implement this? 😍

Go has a semaphore which uses to schedule and deschedule goroutines.

This approach isn’t without its drawbacks. The Go runtime adds another layer of sophistication around the semaphore - sync.Mutex

sync.Mutex is a hybrid lock. Comparison with pthreads. @kavya719 at @qconnewyork

At a high enough level of concurrency, in Go you end up paying the cost of thread context switching.

It’s locks all the way down! @kavya719 at @qconnewyork

Using formal laws of performance to find understand the effects of contention and coordination on scalability. @kavya719 at @qconnewyork

There’s a plethora of tools available to profile application. First find out if there’s a contention problem.

And some strategies to deploy if contention is indeed the problem.

@kavya719 at @qconnewyork