Re: [boost] [log] Release Candidate 4 released

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.

http://tinyurl.com/ycowsfy