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
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. :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk