Boost logo

Boost :

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

On 01/30/2010 07:01 PM, vicente.botet wrote:
> Hi, I'm interested in knowing how the Asynchronous sink frontend is
> implemented. Do you use a single queue or one queue by thread?

There is a single lock-free queue per sink frontend.

> In "Why log records are weakly ordered in a multithreaded
> application?" you present two possible solution:
> * Strict serialization ( drawback:log records that otherwise could be
> processed concurrently would have to go serial)
> * Ordering
> asynchronous sink frontend (drawback: the order is not completly
> ensured if a thread blocks during more than the latency parameter)
> Maybe we can mix both. We can manage with a single log counter that
> is increased each time a log is done. The time spent to increase this
> counter atomicaly shouldn't have a deep impact on the concurrency of
> logs, isn't it? Each log will have a counter attribute that will
> ensure a complete order of logs. We could have an asynchronous sink
> that will pass the logs to the back-end in the order given by this
> counter. Of course this will introduce a latency between the source
> logging and the time it is given to the back-end sink, but any
> asynchronous sink will suffer form the same symptom.
> Do you think that something like this could be included in your
> library?

You basically describe the second point (record ordering). The library
already supports record ordering in a special frontend. With this
frontend one may order records not only by a counter (which will
eventually roll over and break the ordering) but by any attribute, time
stamps for instance.

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