Enokida wrote:
My developing function consists of shared libraries that is thread safe.
This shared library can be called by both nonthreaded programs and multithread
programs. I don't want to provide two shared libraries for nonthreaded programs
and for multithread programs. For this reason, I want to provide only shared
libraries compiled with the -D_POSIX_C_SOURCE flag and linked with
libpthread.so for multithread programs.
However, there are the following descriptions on Solaris' Multithreaded
Programming Guide.
Do not link a nonthreaded program with -lthread or -lpthread. Doing so
establishes multithreading mechanisms at link time that are initiated at
runtime. These slow down a single-threaded application, waste system resources,
and produce misleading results when you debug your code.
When a nonthreaded program runs on before Solaris 9, four more threads run as
follows.
(dbx) lwps
*>[EMAIL PROTECTED] breakpoint in main()
[EMAIL PROTECTED] running in _signotifywait()
[EMAIL PROTECTED] running in ___lwp_mutex_lock()
[EMAIL PROTECTED] running in __lwp_sema_wait()
o [EMAIL PROTECTED] syscall return 159 in _lwp_s
What problems do I have by providing only shared libraries compiled with the
-D_POSIX_C_SOURCE flag and linked with libpthread.so for multithread programs?
You don't need to link with any thread library. In previous
releases of Solaris, no-op versions of the thread routines were
provided in libc so that applications that were not threaded could
use mt-safe libraries; the mutex calls, etc, were no-ops. In Solaris
10, lib*thread was merged with libc and the need for such subterfuge
was eliminated. Today, a call to *mutex_lock generates a simple store
if the application is multi-threaded and a atomic op if more than
one thread has existed in the program.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
