this is a bunch of sketches to help compare latencies of various thread-synchronization primitives under linux. by "latency" i mean "how long does it take between dispatching a notification does it take to receive it?" the test case here is designed mainly to imitate inter-thread message queues (like Go's channels, or actor mailboxes), where one thread spends most of its time blocked, waiting for notifications/messages from another thread(s).

the testing methodology is, roughly, to spin up several pairs of threads (one reader and one writer per pair). the writer will sleep, retrieve the current high-resolution system time, wake up the reader, and sleep again. the reader will wake up, get the current system time, compare it with the writer's time, and print out the time delta. each pair differs only in how long the writer sleeps.

let's see what's on the menu in `src`:

  - `src/control.c` is our "control". it tests two clock_gettime() calls
	back to back in a single thread to estimate how long it takes
	to get the current high-resolution time.

  - `src/pthread_condvar.c` uses pthread condition variables to
	synchronize access to a struct timespec.

  - `src/posix_sem.c` same as above, using POSIX semaphores instead of
	pthread condition vars

  - `src/pipe_blocking.c` reader thread blocks on read(), writer thread
	writes a single byte to the pipe

  - `src/pipe_nonblock.c` same as above, but pipe is O_NONBLOCK and
	reader thread blocks in poll()

  - `src/eventfd_blocking.c` and `src/eventfd_nonblock.c` are the same
	as the pipe tests, but using the Linux-specific `eventfd(2)`
	interface instead of anonymous pipes.

before you ask: yes, this is all very much in the realm of micro-optimization. however, in certain applications, every fraction of a millisecond can count: in real-time graphics code, you've generally got less than 20 milliseconds to render a frame if you want it to look smooth, and in real-time audio the margins are even smaller (especially when low latencies are involved). there's no shortage of choice for thread synchronization methods these days, all with their pros and cons, so i figured i'd add another few data points to the mix.

to build:

    $ make

to run the tests:

    $ make test

questions, comments, and/or field recordings to [email protected]
thx