Boost.Thread documentation

[Valentin Shtronda <valiko.ua@…>]

The following phrase under UpgradeLockable Concept should be corrected (it was copy-pasted from SharedLockable Concept without change):

"A type L meets the SharedLockable requirements if it meets the TimedLockable requirements and the following expressions are well-formed and have the specified semantics."

->

"A type L meets the UpgradeLockable requirements if it meets the SharedLockable requirements and the following expressions are well-formed and have the specified semantics."

[viboes]

Committed in trunk revision 80517.

[Valentin Shtronda <valiko.ua@…>]

More cosmetic issues on the same page: 2) Extra bracket: m.unlock_upgrade_and_lock();] -> m.unlock_upgrade_and_lock();

3) This phrase looks corrupted: "Let pm be and owns the ownership state."

[Valentin Shtronda <valiko.ua@…>]

4) There are many double underscores () in the text that seems need to be corrected.

[Valentin Shtronda <valiko.ua@…>]

4) for example, __shared_lock_guard_ca -> shared_lock_guard

[Valentin Shtronda <valiko.ua@…>]

5) Documentation for "BasicLockable Concept::unlock()" says it does not throw but implementation throws exception if lock is not owned.

[viboes]

Replying to Valentin Shtronda <valiko.ua@…>:

5) Documentation for "BasicLockable Concept::unlock()" says it does not throw but implementation throws exception if lock is not owned.

Please, could you point where the implementation is throwing?

[viboes]

I have updated the doc to fix the typos.

Committed in trunk revision [80565].

[Valentin Shtronda <valiko.ua@…>]

Replying to viboes:

Please, could you point where the implementation is throwing?

boost_1_51_0\boost\thread\locks.hpp, lines 598, 869, 1100.

[viboes]

Committed revision [80668].

[viboes]

Replying to Valentin Shtronda <valiko.ua@…>:

Replying to viboes:

Please, could you point where the implementation is throwing?

boost_1_51_0\boost\thread\locks.hpp, lines 598, 869, 1100.

It would be great if unique_lock/shared_lock BasicLockable but they aren't. Where have you read that the locks defined there are a model of BasicLockable?

[viboes]

Replying to viboes:

Replying to Valentin Shtronda <valiko.ua@…>:

Replying to viboes:

Please, could you point where the implementation is throwing?

boost_1_51_0\boost\thread\locks.hpp, lines 598, 869, 1100.

It would be great if unique_lock/shared_lock BasicLockable but they aren't. Where have you read that the locks defined there are a model of BasicLockable?

Hrr, I've found it

"

Specializations of boost::unique_lock model the TimedLockable concept if the supplied Lockable type itself models TimedLockable concept (e.g. boost::unique_lock<boost::timed_mutex>), or the Lockable concept if the supplied Lockable type itself models Lockable concept (e.g. boost::unique_lock<boost::mutex>), or the BasicLockable concept if the supplied Lockable type itself models BasicLockable concept.

"

I will remove this with a note explaining why they are not model of TimedLockable.

[viboes]

Replying to viboes:

Replying to viboes:

Replying to Valentin Shtronda <valiko.ua@…>:

Replying to viboes:

Please, could you point where the implementation is throwing?

boost_1_51_0\boost\thread\locks.hpp, lines 598, 869, 1100.

It would be great if unique_lock/shared_lock BasicLockable but they aren't. Where have you read that the locks defined there are a model of BasicLockable?

Hrr, I've found it

"

Specializations of boost::unique_lock model the TimedLockable concept if the supplied Lockable type itself models TimedLockable concept (e.g. boost::unique_lock<boost::timed_mutex>), or the Lockable concept if the supplied Lockable type itself models Lockable concept (e.g. boost::unique_lock<boost::mutex>), or the BasicLockable concept if the supplied Lockable type itself models BasicLockable concept.

"

I will remove this with a note explaining why they are not model of TimedLockable.

Howard Hinnant gave me the answer. "In the BasicLockable requirements it says that it is undefined behavior to call m.unlock() unless the current execution agent holds the lock on m. And the only time shared_lock<shared_mutex>/unique_lock<mutex> could throw on unlock is if owns_lock() is false."

So perhaps the library is good after all.

I will close the issue. Please reopen it you don't agree.

[Valentin Shtronda <valiko.ua@…>]

viboes, I cannot find information about undefined behavior on this page: http://www.boost.org/doc/libs/1_51_0/doc/html/thread/synchronization.html Where do you see this? Even if it's said somewhere, I still find "Throws: Nothing" clearly saying it never throws. Look at documentation for m.lock(): it clearly says it can throw if an error occurs. Documentation for unlock() would be more helpful if it said that it can throw if lock is not owned.