Boost logo

Boost :

Subject: Re: [boost] [log] Release Candidate 4 released
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-01-30 14:56:28

>> There is a single lock-free queue per sink frontend.
> Have you considered to have one queue by thread, this could reduce
> contention as source threads will not share the same queue. In this
> case the kind of queue you need has only one producer thread and one
> consumer thread, which has more efficient lock-free implementations
> (at least this is what I have heard).

Yes, I have considered this idea. IMHO, it won't give much performance
benefit, compared to a single lock-free queue, unless all your
application does is logging alone, from dozens of threads. I did not
experiment, though, so I don't have numbers behind myself.

I have plans of redesigning the queue in order to allow to limit its
growth, which may be required in heavily loaded applications. Per-thread
queues would complicate this addition.

>> With this frontend one may order records not only by a counter
>> (which will eventually roll over and break the ordering)
> You can define an order that takes care of roll over. It is enough
> that the distance between two samples don't saturate the counter
> type.

Technically, you can't define a reliable distance between counter
samples, because it's always possible that a record from a low-priority
thread will have the counter value beyond it.

>> but by any attribute, time stamps for instance.
> On some platforms time stamp it is not enough, as several logs can
> share the same time stamp when the clock is not enough precise. You
> will need in addition a sequence counter to get a complete order.

Well, from the observer's point of view, records that have the same time
stamp were emitted simultaneously. It's undefined which of them happened
first, thus no point to define their order in log. One might want to
improve the time stamp precision to get a more crisp picture of
inter-thread relations.

However, you are free to order records as you will. You can define the
ordering based both on the time stamp and the record counter.

> IMO what the user needs is an complete order related to the time
> point where the log was sent. I don't see other orders that could
> interest the user, do you have some examples?

You can't implement a complete order, just the order within an ordering
window. But yes, the main aim of this functionality is to maintain
chronology of log records.

Boost list run by bdawes at, gregod at, cpdaniel at, john at