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