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

Subject: Re: [boost] [log] Release Candidate 4 released
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-01-30 13:43:08

----- Original Message ----- 
From: "Andrey Semashev" <andrey.semashev_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, January 30, 2010 5:09 PM
Subject: Re: [boost] [log] Release Candidate 4 released

> 
> 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.

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). 
 
>> 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. 

I know. I've described the drawback of the current approach on my post.

> 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.

> 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.

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?

Best,
Vicente