
Hi I'm really interested by the new Log library. I would like to know if there is a part of this API that could be wait free, not the << operator perhaps, but a specific function to log a message without having to worry about a malloc or lock called inside the library. I would like to use this from a time critical thread. thank you

On Monday 29 April 2013 23:07:32 adrien courdavault wrote:
Hi
I'm really interested by the new Log library. I would like to know if there is a part of this API that could be wait free, not the << operator perhaps, but a specific function to log a message without having to worry about a malloc or lock called inside the library. I would like to use this from a time critical thread.
The library is not lock-free, it will have to allocate dynamic memory and obtain locks when processing log records (but not when you call operator<< while composing the message). However, the library is quite friendly to multithreaded applications. It uses shared locks internally when possible, so different threads can process records simultaneously. Synchronous sinks will block on contention, although the library tries to avoid that when multiple sinks are used. You can try using asynchronous sinks if that's the problem. asynchronous_sink<T, unbounded_fifo_queue> uses a lock-free queue internally, so it will avoid locking. Other types of queues will still use locking but the probability to block on these locks is quite low. I would also recommend using a decent memory allocator with the library, such as TCMalloc. It uses thread-specific memory pools, which makes memory allocations very fast and maybe even lock-free, although I haven't checked that specifically.

Hi Yes that is what worried me, I can't have any operation like lock or classic malloc in my thread. I could use a specific allocator for preallocation, But I would more need a queue like LockFree. and it would obviously be asynchronous, I know that the consequences (problem of message ordering, limis in message rate because of the no allocation on the source side) But that would realy be what I need. Thank you for your answers On 30 April 2013 05:41, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Tuesday 30 April 2013 07:32:06 you wrote:
asynchronous_sink<T, unbounded_fifo_queue> uses a lock-free queue internally, so it will avoid locking.
Ughh, I just remembered there is also a lock in this case, so technically it's not lock-free either. Sorry.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Thu, May 9, 2013 at 6:00 PM, Julien Nitard <julien.nitard@m4tp.org>wrote:
My interpretation of a log library should be multiple producer single consumer, is there such a lockfree library (not patented) that boost could use ?
Boost.Log has an internal thread safe queue. It is not lock-free but it is quite efficient. There is Boost.LockFree library, although its data structures impose certain requirements on the stored types that are not suitable for Boost.Log.
participants (3)
-
adrien courdavault
-
Andrey Semashev
-
Julien Nitard