Realistically, what pthreads functionality is generally used?

Question

Hi,

I'm working on the POSIX subsystem of my operating system project, and I've reached the point where I would like to work on pthreads support. However, I'm not certain about the extent to which I should implement them.

What is the most-used pthreads functionality? Is there anything I could safely "just stub out" for now and implement it when we port an application that requires it? My research so far points to the basic thread operations (create, join, etc...) - that's quite obvious - and mutex support. Realistically speaking, do applications use much more than this?

I guess I'm just trying to figure out how little I can get away with while still having a working implementation.

Answer 1

You will definitely need to support mutexes and conditon variables, because threading would be unuseable without them, and they are both widely used. I suppose you could get away without supporting semaphores (which aren't part of pthreads, I think), but I can't imagine doing any serious MT work without them.

It might be interesting to look at the next proposed C++ standard which will support threading and implement the features that it requires. If your OS can support future Standard C++ programs, it would be in pretty good shape.

Answer 2

I'd suggest a bare bones pthread implementation cover the following functions (with "pthread_" prefixes removed):

• basic thread operations
  create, exit, join, detach, self, equal, and "attr" support of joinability/detachability
• process integration
  atfork, kill and sigmask
• synchronization primitives
  cond and mutex functions (default attributes only -- nothing fancy!), possibly omitting cond_timedwait

Take a look at the SUSv6 entry on <pthread.h>, which I link in preference to SUSv7 because version 6 has more option groups called out in this header. I composed the above list by striking any optional features, and then dropping other sets of functionality that my personal history and observation suggest are inessential (e.g., thread-specific data) or both inessential and dangerous (e.g., thread cancellation). :)