making a library MT-safe
Mikael Lindkvist
I have made a programming-library that is currently MT-unsafe. The
unsafety is due to the use of shared objects and the use of the same
sockets from different functions in the library. Possibly I have to
rethink this design, by I would rather find some other solution. The
best thing would be to use critical sections. The problem is that I
don't want the library to depend on a particular threadlibrary. So my
question is, is it possible in any way to implement critical sections
without a thread-library?
On SGI's discussion on threadsafety and STL
(http://www.sgi.com/tech/stl/thread_safety.html) they talk about lock
implementation. Here they mention "spin-locks". What are "spin-locks"?
Anything related to my problem?
// Mikael
David Butenhof
> I have made a programming-library that is currently MT-unsafe. The
> unsafety is due to the use of shared objects and the use of the same
> sockets from different functions in the library. Possibly I have to
> rethink this design, by I would rather find some other solution. The
> best thing would be to use critical sections. The problem is that I
> don't want the library to depend on a particular threadlibrary. So my
> question is, is it possible in any way to implement critical sections
> without a thread-library?
"Using the same socket" doesn't necessarily mean the code isn't
thread-safe. The socket interfaces should be expected to be thread-safe on
any reasonable system, and the worst that'll happen to your code is that
you may get confused by changes in the order of messages. If that's a
problem, though, you need more than just "a critical section": you'd need a
mechanism to control the ORDER of messages.
And, no, you really can't create a meaningful/relevant/efficient/safe
critical section without a thread library. At least, not if the concurrency
against which you're trying to protect is created through the use of a
thread library.
On many systems, the C runtime library (libc, glibc, etc.) includes "stub"
entry points for the pthread synchronization functions. You can
"initialize", "lock", and "unlock" mutexes without a thread library. That
allows you to write your code using explicit synchronization, and it'll
resolve and run correctly even without a thread library that implements the
functions. (But without actual synchronization.) A thread library will
preempt those symbols and do actual synchronization. If your system (e.g.,
Linux) supports several different thread libraries, and each implements the
proper interfaces, it'll still work -- at least as long as nobody tries to
pull in more than one at a time. ;-)
> On SGI's discussion on threadsafety and STL
> (http://www.sgi.com/tech/stl/thread_safety.html) they talk about lock
> implementation. Here they mention "spin-locks". What are "spin-locks"?
> Anything related to my problem?
No. A spinlock is a machine-specific "optimized" form of mutex ("MUTual
EXclusion" device). However, you should never use a spinlock unless you
know that you have multiple threads and that you're running on a
multiprocessor. Otherwise, at best you're wasting a lot of time. A spinlock
is great for "highly parallel" algorithms like matrix decompositions, where
the application (or runtime) "knows" (or at least goes to lengths to
ensure) that the threads participating are all running at the same time.
Unless you know that, (and, if your code doesn't create threads, you CAN'T
know that), don't even think of using a spinlock.
/------------------[ David.B...@compaq.com ]------------------\
| Compaq Computer Corporation POSIX Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----[ http://home.earthlink.net/~anneart/family/dave.html ]-----/