Re: Moving pthread_(cond|mutex) to libc

[David Holland <dholland-tech%netbsd.org@localhost>]

On Fri, Jan 25, 2013 at 01:19:22PM -0500, Mouse wrote:
 > >> If I'm writing a library, and I want the library to be safely usable
 > >> by both threaded and unthreaded programs, is there anything I can
 > >> do?  Right now it seems the only fully viable approach is to build
 > >> two versions and hope I can figure out how to get clients to link
 > >> the right one, which is pretty sketchy.
 > 
 > > You can [...].  Applications which want the specific functionality in
 > > the API that requires threads link with -lose.  Applications that
 > > want the subset of the API that does not require threads link with
 > > -luse.
 > 
 > How is this not "two versions and hope [] clients [] link the right
 > one"?
 > 
 > Also, it's not necessarily a case of a subset of the API requiring
 > threads.  I suspect more likely is that the API is not explicitly
 > thread-aware, but behind-the-scenes locking is required when running
 > threaded.

Right, that.

No threads in the API, and the library does not call pthread_create,
but it does have internal global data that needs to be locked if more
than one thread's going to be in the library at once. (And also, if
there isn't going to be more than one thread, it would like to not pay
the locking overhead.)

It could be split into two libraries where the main library contains
locking stubs and the threaded library contains real locking
operations (just like libc) but then we're still left with the problem
that somehow threaded programs need to know to link in the extra thread
support library. And worse, if they don't, it fails silently.

-- 
David A. Holland
dholland%netbsd.org@localhost