|
|
Threads-Devel : |
From: Anthony Williams (anthony_at_[hidden])
Date: 2008-01-07 10:32:27
Quoting Michael Gopshtein <mgopshtein_at_[hidden]>:
> I agree that the concept of "thread storage" is more closely assosiated with
> thread's private data. The situation where we use such iterator is the
> following: assume that your data structure supports simultaneously 1 reader
> and 1 writer with no locking, but does not support 2 or more writers. The
> most trivial example: int counter (say, for statistics). You can increment
> it in one thread, and read the value in the other, but you can't increment
> it in 2 threads without a lock.
OK.
> So continuing this example, assume that each thread maintains a counter, and
> you want to get a sum of all counters for all threads - in this case such
> utility would be useful.
OK.
> Adding external map of such local objects is possible, but this introduces
> additional level of complexity, as you have to make sure to remove those
> objects when the thread exits.
You can always use boost::this_thread::at_thread_exit to register a
cleanup function.
The alternative is that this complexity is forced on all users of
thread_specific_ptr, which is a bad thing.
Anthony
-- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL