Thanks, Bill. No problem. I can declare a mutex but it doesn't have the lock/unlock methods described in the documentation-- the only thing that's public is the constructor/destructor. Could I have botched my installation of boost somehow? I just got it out of synaptic, thinking that that would be the least error-prone way to go. You do not have the latest version of boost, it's newly released and will not be in any repositories yet. Your version probably included the documentation, it may be easier for you to read this locally as there are many changes incorporated in the latest release. Alternatively if you are just experimenting (i.e. not using the libraries in existing

Also, in the interest of all that "teach a man to fish" stuff so I can quit bothering you, is there a document somewhere that explains what a "concept" is in boost terms? (ie, is it a design specification for developers to work off of, or is it a pure virtual class actually described in a .hpp file somewhere?) In the context I was talking about concepts are design requirements for types that are to be used to instantiate templates. The language will be changed to directly support concepts so the compiler can check that the types provided as template arguments fulfill the concept requirements. In the meantime while we wait for compiler support, concepts can be checked with library code. It is worth noting that concept checking is

Henry Holmes wrote: projects) you could easily download and build the latest version. The latest version of boost (1.35) changes this, in previous versions the lock() and unlock() operations on the mutexes were indeed not public. This was because the library author felt that using them directly is unsafe and unnecessary. To acquire and release the mutex lock you delegate the job to a second type which has access (via friendship prior to 1.35) to the lock state changing operations. The second type allows a RAII type mechanism to manage the lock state safely. This approach allows a mutex's lock state to be set (acquired) over a scope and is safer especially if the scope is exited due to an exception. See examples in the library docs for usage, but it goes like this: typedef boost::mutex lock_t; typedef lock_t::scoped_lock guard_t; lock_t lock; //... { // some block requiring thread exclusive access to some resource guarded by lock guard_t guard(lock); // from here until guard is destroyed mutex is acquired // do stuff to resource } // guard destroyed here however block scope is exited which releases mutex lock Type names and behaviour have changed in 1.35 but principles are the same. mainly a tool for template library authors although documenting the concepts can be a very powerful way of showing how a library is intended to be used or extended. Boost provides a concept checking library http://www.boost.org/doc/libs/1_35_0/libs/concept_check/concept_check.htm which explains far better than I can.

Thanks, Henry

Hi Henry,

Henry Holmes wrote:

...

Sorry if this is a dumb question-- it looks like just about every kind of lock/mutex I could declare in the documentation wants to be passed a Lockable object, but I can find no such thing in any of the header files. I have the Boost Thread library installed and am able to make and run threads, and I have all sorts of other lock and mutex stuff defined, it just does not seem to correspond to the documentation at all. Am I just horribly confused about what the documentation means? Any help is greatly appreciated. Lockable is not a type, it is a concept. Concepts are requirements a type must comply with to be used by a type or function. The Lockable concept is defined here http://www.boost.org/doc/libs/1_35_0/doc/html/thread/synchronization.html#th...

. The boost thread library provides types that implement these concepts and they may be substitued where a suitable concept is required. This is a form of polymorphism you may not be aware of. The types you may want to instantiate for your requirements are probably described here http://www.boost.org/doc/libs/1_35_0/doc/html/thread/synchronization.html#th...

note that they all implement at least the Locakble concept.

HTH

-- Bill Somerville --

Bill Somerville Class Design Limited