Re: Stream thread-safety
On Feb 13, 10:49 am, "Chris Thomasson" <cris...@comcast.net> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:c7ca300d-f325-4cd2-bdf6-946bce9e8757@v67g2000hse.googlegroups.com...=
On Feb 13, 6:51 am, "Chris Thomasson" <cris...@comcast.net> wrote:
[...]
Thread-Safe in what context? basic or strong?
I'm not familiar with those terms. Thread safe means,
basically, specifying how objects of the class must behave in a
multithreaded environment.
[...]3
Darn... I was thinking of something else.
To the OP: in order to sync stream objects, you need a level
of coarse-grain external sync... *Or* here is a possible
scheme that can increase granularity and scalability:
http://groups.google.com/group/comp.programming.threads/msg/3f0362ba3...
That's one solution. For logging, I generally use a temporary
instance of a wrapper class---the constructor acquires the lock
(and also sets up various other things, like ensuring a time
stamp and other standard information appears at the start of the
record), and the final destructor frees it.
This has the advantage that the tests whether logging is active
at the desired level occur immediately---since they only access
read-only data, no lock is necessary, and if logging is not
active, no lock is acquired, nor is much of anything else done.
Which means that you can throw in debug logging statements all
over the place without noticeably slowing the application down.
That being said:
__________________________________________________________________
http://www.boost.org/libs/smart_ptr/shared_ptr.htm#ThreadSafety
the ("Any other simultaneous accesses result in undefined
behavior." clause contained therein means that shared_ptr,
__as-is__, only follows "basic/normal" thread-safety level)
Note that shared_ptr pose a particular problem, because part of
the state is shared between different instances, and the client
code may not be aware of this. So you have to define your
guarantees very carefully.
Anyway, here is a fairly lengthy discussion on the difference
between basic/normal and strong thread-safety levels:
http://groups.google.com/group/comp.programming.threads/browse_frm/th...
(this thread substitutes the thread-safety level term 'normal'
with 'basic', and vise-versa, as they are one in the same...)
For some working examples, the following code can handle both
basic _and_ strong models:
http://groups.google.com/group/comp.programming.threads/browse_frm/th...
http://home.comcast.net/~appcore/vzoom/refcount
http://atomic-ptr-plus.sourceforge.net
http://groups.google.com/group/comp.programming.threads/browse_frm/th...
(POSIX based version)
Does that help clear some things up? If not, perhaps we can
enlighten some of the people who lurk around this group...
Any questions?
My main point was that whatever level you decide to implement
(and there are definitly more than two possible levels), what
makes code "thread safe" is the contract. Correctly documented
and implemented in consequence, even something like localtime()
is thread safe. (Posix, of course, chose the option to NOT make
any thread related contract apply here. A reasonable decision:
given the interface, any possible contract would be extremely
constraining on the user, and offering a new function, with a
contract more in line with the general principles of Posix, is
probably a better solution.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34