51–56 of 56 posts
Much better to just get the time every once in a while and cache it.
Earlier quoted context omitted.
I think you misunderstand the CAS operation. It performs an atomic compare and swap on a pointer (32 or 64 bits), so obviously it requires no coordination to switch out the head pointer of a stack. For example, on an LP64 architecure: Item * first = writers.first; while( CAS((long *)&writers.first,(long)0,*((long*)&first)) != *((long*)&first)) { first = writers.first; } Here first represents the flush stack, and writ…
No, I'm saying you have coordinated the writing to the stack. It's not enough to just swap pointers to the stacks themselves, but you have to know how much data has been written to the stack. Perhaps your description is incomplete?
However, if you need to know the count/size...
Then in general you must accept that the count/size of the write stack is dynamic, so even if you use an integer to track the value (and keep updated with atomic exchange or increment), at the point that you read its value on one thread it may have already changed on another.
So it doesn't really matter if you reset the value to 0 using an interlocked exchange (this cant be done as an atomic unit with respect to the head pointers unless your platform supports a double CAS). Some loss of count/size information will occur.
Alternatively you can safely iterate through the stack to calculate the count/size anytime you need it (provided the next pointers are also treated atomically).
Neither option will give you the exact size since as discussed above its always dynamic, but this i no way impedes the functioning of the write/flush stacks as described. In my solution i just set the value of the count/size to 0, and disregard any loss of information since it is not critical.
I'm not sure if it's just me, but I found the lack of reference to system time interesting. Maybe it's one those things everyone does (but never talks about), but if you're logging, one of the absolute performance killers can actually turn out to be getting the system time via gettimeofday() or whatever. That's a syscall which involves a context switch, which... (It goes downhill from there.) Much better to just get…
> A key requirement for logging is to write statements, from any thread, in order, to a single log-file. I do not agree that it's a necessary requirement that all threads must write to a single log-file. > Formatting strings, required by a log system, is a slow operation. I also do not agree that it's a necessary requirement that a log system must format strings. Binary log files have their uses. I've used Google Pro…
Earlier quoted context omitted.
No, I'm saying you have coordinated the writing to the stack. It's not enough to just swap pointers to the stacks themselves, but you have to know how much data has been written to the stack. Perhaps your description is incomplete?
The stack head pointers can be swapped and flushed without knowing how much data is in it. However, if you need to know the count/size... Then in general you must accept that the count/size of the write stack is dynamic, so even if you use an integer to track the value (and keep updated with atomic exchange or increment), at the point that you read its value on one thread it may have already changed on another. So it…
Excuse me but I'd like to have it clearly stated: which information is actually lost in your implementation? Do some of the messages passed to be written actually end not being written? Which part ends up not knowing count/size?
> A key requirement for logging is to write statements, from any thread, in order, to a single log-file. I do not agree that it's a necessary requirement that all threads must write to a single log-file. > Formatting strings, required by a log system, is a slow operation. I also do not agree that it's a necessary requirement that a log system must format strings. Binary log files have their uses. I've used Google Pro…
FWIW, CloudFlare uses Cap'n Proto for logging.
;-)