|
Boost : |
From: Chuck Messenger (chuckm_at_[hidden])
Date: 2003-05-24 09:14:08
I've been experimenting with the thread lib. I found a bug related in
some way to thread_specific_storage (tss). In particular, I #ifdef'd
all the tss stuff out, using native pthread calls instead, and
everything worked as expected.
So, I went back through, trying to determine what could be going on.
I'm using tss to store a pointer to a thread-wide structure.
thread_specific_ptr<mythread*> current_thread;
mythread *mythread_get() {
return *(current_thread.get());
}
static int init() {
// Need to initialize thread local storage for main thread
// XXX I'd like to put something here to ensure that
// current_thread has been constructed. But what?
current_thread.reset(new mythread *);
*(current_thread.get()) = new mythread;
return 0;
}
static int val = init();
The problem is that I can't be sure, during init(), that current_thread
has been constructed. I believe that's at the root of the bug I'm tracking.
By contrast, in my pthread-specific code, I simply put the
pthread_key_create() call at the start of init(), thus ensuring proper
initialization order. But there's no analogous call I can make for a
thread_specific_ptr -- that call is done during construction time.
So, what to do about it? Well, one obvious solution is to indirect
current_thread:
thread_specific_ptr<mythread*> *current_thread;
then construct current_thread during init(). But that gives me yet one
more indirection I have to do during mythread_get(). It's already slow
as it is.
Any suggestions?
Which brings me to another source of slowness: because
thread_specific_ptr automatically invokes delete on a thread's tss
pointers when the thread goes away, I can't put a pointer to my real
object, like this:
thread_specific_ptr<mythread> current_thread;
because mythread can't be deleted (for arcane reasons I won't get into
here). It would be nice if there were a version of thread_specific_ptr
which didn't delete, e.g.:
thread_specific_ptr<mythread, non_deleting> current_thread;
Just a suggestion...
- Chuck
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk