Re: Stream thread-safety
On Feb 14, 11:40 am, "Chris Thomasson" <cris...@comcast.net> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:cb6668c7-1cfa-4229-b5b2-bda253bc83b5@e25g2000prg.googlegroups.com...
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.co=
m...
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.
Yup. You are referring to on-stack logger instance. I also want on-stack
log-producer, with a log-consumer thread on the other side. I don't want l=
og
threads to execute final output commands. I want to use shared monotonic
counter to assign log-entries a ordered timestamp (e.g., think Lamport). T=
he
log-consumer will be able to query it's registered threads for log info;
order any results; then output. Advantage being that you have low-overhead=
log-producers, and totally ordered log output wrt the dedicated log-consum=
er
logic.
I've used both solutions at different times. With everything
done in the thread generating the log, you hold the lock a lot
longer, which can significantly affect latency. On the other
hand, in case of a crash or such, any logs triggered before the
crash in the thread which crashed are guaranteed to have been
output. It's a bit more reliable for debugging. (In once case,
the logging thread was in another process, communicating via
shared memory, precisely to avoid this problem while still using
the log-consumer thread model.)
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.
BTW, can your read-only data wrt loging rules mutate over application
lifetime? The soultion above has per-thread rules, and a GUI application c=
an
issue writes into the PDR reader-pattern based distributed log-info (e.g.,=
per-thread info that is)...
To date, I've not had to handle the case where the configuration
data could be changed while running AND we had multi-threading.
I've thought about it, though---the only solution that came to
mind immediately was to use a rwlock, held for read by all of
the threads, except when they are going to block; the thread
which will modify the configuration acquires it for write.
I don't want to use a mutex around the check whether a specific
level of logging is active; that check should be as fast as
possible.
The log-level validation information can be per-thread, or in a global
lock-free PDR protected data-structure (e.g., think RCU for a moment) such=
that log-threads are readers and log-level mutation operations would execu=
te
on writers. This would allow for a GUI application to dynamically set
logging rules on a pr-thread basis at runtime. Search
comp.programming.threads for PDR for more info...
If the need arises, I'll certainly research the topic; I'm sure
that there are better solutions than the one off the top of my
head. (There are a lot of issues that I've not investigated,
simply because I've not needed them yet.)
--
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