Thank you for your reply.
I think from the following display of lwps command of dbx that when a
nonthreaded program,
which is thread-unsafe and linked with libpthread.so, calls my shared library,
four more threads
are created, and then main thread plus the four threads run at the same time
because my shared
library is compiled with the -D_POSIX_C_SOURCE flag and linked with
libpthread.so.
Do four threads except main thread cause problems for thread-unsafe caller
program?
Enokida
Sent: Wednesday, February 21, 2007 3:19 AM
Subject: Re: [osol-code] Any problems with providing only shared librarys
linked with libpthread.so
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
