RE: Thread-safe libio [was Re: BUG in libstdc++ ... libio ... pthreads]

["Edwards, Phil" <pedwards@ball.com>]

+ #1 Synchronization mechanism
[snip]
+  b) use a mutex to protect the buffers.
+     Advantage: possibly more efficient
+     Disadvantage: ?

Possibly more efficient than... what?  flockfile()?  Could be.  If we don't
want to do a bunch of system calls (on whatever platform), we should use an
exclusion mechanism that runs in user space.  POSIX would be wonderful, but
my experience thus far is that it's still being tweaked and debugged in the
most common platforms.

I wrote a semaphore wrapper library to help protect client code from this.
I'm in the midst of rewriting it to use either POSIX, or native Unix
semctl()-family, or native Win32 stuff as its underlying implementation,
chosen at compile time.  Thus, synchronization sections of client code are
transparently portable.  Doing it isn't all that difficult, but making the
wrappers /efficient/ is troublesome.

We would either have to use a similar wrapping method, or try POSIX (since
we're discussing pthreads anyhow), or...?


+ #2 Choosing thread-safety
+ The user should be able to choose between a thread-safe and a
+ non-thread-safe implementation; preferably on a per-object basis. This
+ could be supported by:
[snip a couple of ideas with "disadvantage:  non-standard extension"]

If we give them that choice, it'll be non-standard /however/ we do it.  :-)
Every method I think of gets shot down by my own brain before I finish
typing the paragraph, however.


Phil
(If you reply to the list, please don't cc another copy to me.  Thanks.)