In boost::log documentation, there's some code as following:
* typedef attrs::mutable_constant< int> int_constant_t; boost::shared_ptr< int_constant_t> attr(new int_constant_t(-5)); lg.add_attribute("MyInteger", attr); BOOST_LOG(lg)<< "This record has MyInteger == -5";
**// Change the attribute value attr->set_value(100); BOOST_LOG(lg)<< "This record has MyInteger == 100"; * Now I have a situation in my multi-threading app: the 'attr->set_value()' could be called in different threads, so the following 'BOOST_LOG(lg)...' could access wrong attributes that is set by another thread. If I use a mutex to protect this, it would be stupid, because the log line might be filtered out, that means the 'locking mutex' is not neccessary.
If thread synchronizaion is what bothers you, mutable constant has internal locking ability, you can specify mutex and lock types in the mutable_constant template parameters. You can find an example in the docs:
So, when internal locking is used, you don't have to externally synchronize access to this attribute, neither when you update its value nor when you write log records involving it.
On the other hand, if you simply try to tag a specific log record with an attribute (e.g. you want to make sure that a particular record has MyInteger value -5 attached) then thread-specific attributes would be a better option. You can add a scoped thread-specific attribute for this record, this will not affect log records generated by other threads and will not require any synchronization either. You can read more about scoped attributes here:
This is a general comment about the documentation across the boost project and isn't entirely specific to the boost-log project, but wisdom such as this "the application of XYZ feature is ideally suited for the situation ABC" doesn't exist frequently in much of the boost documentation. I don't know if it's in some style guideline someplace, but having been a boost user for ~5yrs now and having forced boost on other developers for a few years now, this is one of the things that I acutely notice/get push back on regarding the boost project (especially when referencing its documentation). I actually just made this comment to Boris, the author of the "Boost Libraries" that one of the things that I like about his book is it actually distills practical examples because the boost docs are more geared toward other Boost developers vs consumers of the libraries. The biggest piece of feedback I get is summed up as, "Boost is high quality, but it requires a high degree of skill to apply. A lot of this is because the docs are frequently very dense and assume equivalent levels of STL competency to decipher what's written. Nine times out of ten, I don't need to customize boost or extend it, I just need to use it and there isn't something that I can easily reference and get what I'm looking for within 15-30min." And I'll admit, it took a good year of hammering away at examples and stubbing out little bits of code here and there before I became familiar and comfortable with implementing boost. Call it a byproduct of the PHP-ization of developers, I dunno, but I think there's a nugget of truth to be had in there (maybe add a quickbook type called "Implementors" with tips/hints? *shrug*). Anyway, Andrey, it'd be keen if you could include a note along these lines in the docs. Maybe a quickbook type for "Implementors." Cheers. -sc -- Sean Chittenden sean@chittenden.org