Boost logo

Boost :

From: Jonathan Wakely (cow_at_[hidden])
Date: 2005-08-12 04:28:12


Neal Becker wrote:

> I started out by trying to figure out if shared_ptr always uses threading.
> A quick look at the jamfiles did not suggest that threading was disabled
> when building single.
>
> Then I tried this:
> nm --demangle libboost_regex-d.a | grep -i thread
> [ lots of threading symbols ]
>
> OK, so why is the single threaded version of a library full of threading
> references? Is this a problem?
>
> Oh, this is gcc/linux system

What are the symbols? Are they gthread_xxx and weak pthread_xxx symbols?

libstdc++ uses gthreads, which is an abstraction over pthreads. In the
libstdc++ library there are weak symbols for some pthreads symbols which
are just empty stubs. Unless -pthreads is given then the empty stubs will
be used (so it's not really doing anything like creating threads or locking
mutexes). If -pthreads is used the real pthreads symbols will override the
weak symbols and provide the real threading support.

I would expect to see something like the following in a non-threaded
binary that uses libstdc++:

080712f4 t __gthread_active_p()
0806a194 t __gthread_active_p()
08049dc4 t __gthread_active_p()
080699bc T std::__basic_file<char>::__basic_file(pthread_mutex**)
080699a8 T std::__basic_file<char>::__basic_file(pthread_mutex**)
0808ef34 d __gthread_active_p()::__gthread_active_ptr
0808f10c d __gthread_active_p()::__gthread_active_ptr
08088c90 r __gthread_active_p()::__gthread_active_ptr
08078eb4 T __error_unthreaded
08090944 D __isthreaded
         w pthread_cancel
         w pthread_getspecific
         w pthread_key_create
         w pthread_mutex_lock
         w pthread_mutex_unlock
         w pthread_once
         w pthread_setspecific
0808ef30 d use_thread_key

jon

-- 
Horms and I discussed this, and we came up with two categories of people.
People who use vim, and people who don't realize that they could be using vim.
	- Geoff Harrison

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk