pthreads are go!

Last night: Madrigal Dinner at NCSU. Too much bread!

This morning: wrote my first multithreaded application using pthreads. It’s based on minimad.c, but with the decoder and output done in separate threads with a threadsafe circular buffer between them. It’s really ugly, but the damn thing works.

BTW: why do separate threads on Linux show up as separate processes under top? That just seems stupid, unless they aren’t really threads at all, in which case they totally suck.

(Update: I found the answer to my question about threading. I’m satisfied for now.)

from http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html

K.1: What is the implementation model for LinuxThreads?
LinuxThreads follows the so-called “one-to-one” model: each thread is actually a separate process in the kernel. The kernel scheduler takes care of scheduling the threads, just like it schedules regular processes. The threads are created with the Linux clone() system call, which is a generalization of fork() allowing the new process to share the memory space, file descriptors, and signal handlers of the parent.

Advantages of the “one-to-one” model include:

* minimal overhead on CPU-intensive multiprocessing (with about one thread per processor); * minimal overhead on I/O operations;
  • a simple and robust implementation (the kernel scheduler does most of the hard work for us).

The main disadvantage is more expensive context switches on mutex and condition operations, which must go through the kernel. This is mitigated by the fact that context switches in the Linux kernel are pretty efficient.

Now to get this thing to crossfade from MP3 to MP3…

2002.11.21 · permalink