[boost] singleton timeout lifetime (was: thread yield)

From: Jason Hise (chaos_at_[hidden])
Date: 2005-09-24 00:20:27

Howard Hinnant wrote:

><nod>  I remember well my first introduction to condition variables.  
>At first they seemed rather strange.  But I view them now as 
>fundamental as a mutex (from a client's point of view).  You just can't 
>live without them.
>
Thanks for the help and code example.  I didn't realize that a condition 
variable was encapsulated inside the boost threads library, and not just 
a general design principle (when I first saw the term, I was thinking 
'volatile bool' :) ).  I think I should be able to make this work now.  
However, I would like to elaborate on a little more of what I am doing 
just in case people more knowledgeable about threading can offer design 
improvements.

Because the singleton library is now being designed to work with shared 
memory in addition to allowing multiple instances in a singleton_map 
(multiton), I have a particularly difficult situation to deal with.  The 
main problem is: when a multiton exists in shared memory, who should own 
the timeout threads associated with each instance?

If the instance were not in shared memory, I could simply make the 
thread a member of the lifetime policy (there is one lifetime policy 
instance associated with each singleton instance).  But if the lifetime 
policy exists in shared memory, it would be possible for the process 
which created the original thread to exit while the lifetime policy and 
singleton instance are still being used by another process.  This would 
result in undefined behavior.

If there were only one instance of the lifetime policy in shared memory 
I could use static bools to track which process has or has not yet 
created a timeout thread for that lifetime policy type, and manage the 
lifetime of each thread on a per-process basis.

But I still have to handle multiple lifetime instances which live in 
shared memory.  I think that the only way to do this is to create a new 
thread every time the instance is accessed, which causes the 'timer' to 
be reset.  The timeout thread main function would then only sleep once, 
after which it would check the current timeout time, decide whether or 
not to destroy the instance, and immediately exit afterward (function 
would contain no loops).

To handle the case where the process exits while some timeout threads 
for that process are still pending, I think I need to maintain a static 
(read process local) collection of thread nodes, with a destructor that 
signals and joins each node in the collection in turn.  (Don't worry, I 
have the means to make sure that this destructor is triggered before the 
lifetime policy instance gets destroyed).  To make sure that this 
collection doesn't grow obscenely large, I can prune the terminated 
threads every time a new thread is added.

Although this solution will probably work, it adds the overhead of a 
thread creation every time the singleton instance is accessed.  Is this 
overhead large enough to be concerned about?  If so, what other options 
do I have?

Please ask me questions if anything written above doesn't make sense.  I 
could really use some help with this scenario, and I hope my verbose 
explanation of the background of the problem doesn't scare people away. :)

-Jason