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
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk