This is the mail archive of the
libstdc++@sourceware.cygnus.com
mailing list for the libstdc++ project.
Thread-safe libio [was Re: BUG in libstdc++ ... libio ... pthreads]
- To: libstdc++@sourceware.cygnus.com
- Subject: Thread-safe libio [was Re: BUG in libstdc++ ... libio ... pthreads]
- From: Andreas Gruenbacher <a.gruenbacher@infosys.tuwien.ac.at>
- Date: Fri, 14 May 1999 12:26:48 +0200
- CC: Nathan Myers <ncm@best.com>
- Organization: Technical University of Vienna
- References: <199905140714.AAA27568@shell7.ba.best.com>
Nathan Myers wrote:
>
> libio itself has support for threads, but the iostream code
> on top of it does not.
>
> > Is anybody working on thread safety currently?
>
> I'm sure a lot of people would like the answer to a different
> question: who would like to work on the thread-safe iostreams?
> Everybody interested, announce and join in!
Well, I'm willing to do some work on that. First, we should discuss
some design issues...
#1 Synchronization mechanism
I agree that there should be some way to access the library from
multiple threads without caring about synchronization. This beasically
means that the library buffers need to be protected from getting messed
up. I can think of basically three ways to implement this:
a) use flockfile() / funlockfile() to lock the file for each I/O
operation.
Advantage: simple
Disadvantage: high overhead
b) use a mutex to protect the buffers.
Advantage: possibly more efficient
Disadvantage: ?
c) Make synchronization an issue of the underlying streambuf.
Advantage: possibly more efficient, mixes with C code
Disadvantage: possible overhead since synchronization happens
at a low level (no "sentry" objects...)
#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:
a) adding a thread-safety flag to ios that the user can set or uclear
(or adding
a similar flag to streambuf, depending on decision #1)
Advantage: low overhead
Disadvantage: non-standard extension
b) providing two sets of classes
Advantage: no overhead
Disadvantage: non-standard extension, makes it tricky to use because
of different classes
#3 More issues: please post...
-----------------------------------------------------------------------
Andreas Gruenbacher, Vienna University of Technology
a.gruenbacher@infosys.tuwien.ac.at
Contact information: http://www.infosys.tuwien.ac.at/~agruenba