Re: Stream thread-safety
"James Kanze" <james.kanze@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.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.
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 log
threads to execute final output commands. I want to use shared monotonic
counter to assign log-entries a ordered timestamp (e.g., think Lamport). The
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-consumer
logic.
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 can
issue writes into the PDR reader-pattern based distributed log-info (e.g.,
per-thread info that is)...
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 execute
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...
Humm. Well, I would expecting very something like:
___________________________________________________________________
struct per_thread_log {
atomicword_rules level;
per_thread_log* next;
per_thread_log* prev;
};
struct per_thread {
per_thread_log* next;
atomicword_rules level;
single_producer_consumer_queue logq;
};
struct log_thread {
per_thread_logging rules;
per_thread_log* head;
per_thread_log* tail;
};
extern per_thread_log(int level, const char* format, ...);
#define LOG_LEVEL_BASIC()0x1
#define LOG_LEVEL_IMPORTANT()0x2
#define LOG_LEVEL_SHI%T_HIT_THE_FAN()0x4
void* some_thread(void* state) {
per_thread_log
log(LOG_LEVEL_BASIC(), "%s\n", "Started...");
if (foo(state) == ERROR_666()) {
log(LOG_LEVEL_SHI%T_HIT_THE_FAN(),
"%s\n", "Stopped...");
}
log(LOG_LEVEL_BASIC(), "%s\n", "Stopped...");
return 0;
}
___________________________________________________________________
[...]