Boost C++ Libraries: Ticket #7370: Boost.Thread documentation

owner, status, version changed

viboes — Thu, 13 Sep 2012 19:03:29 GMT

owner changed from Anthony Williams to viboes
status new → assigned
version Boost 1.52.0 → Boost 1.51.0

milestone changed

viboes — Thu, 13 Sep 2012 19:03:51 GMT

milestone To Be Determined → Boost 1.52.0

Committed in trunk revision 80517.

Fri, 14 Sep 2012 08:13:33 GMT

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

Fri, 14 Sep 2012 08:38:06 GMT

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

Fri, 14 Sep 2012 08:43:48 GMT

4) for example, __shared_lock_guard_ca -> shared_lock_guard

Mon, 17 Sep 2012 16:40:57 GMT

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

viboes — Mon, 17 Sep 2012 21:16:20 GMT

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 — Mon, 17 Sep 2012 21:32:02 GMT

I have updated the doc to fix the typos.

Committed in trunk revision [80565].

Tue, 18 Sep 2012 09:42:35 GMT

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 — Sun, 23 Sep 2012 12:40:34 GMT

Committed revision [80668].

viboes — Sun, 23 Sep 2012 12:48:42 GMT

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 — Mon, 24 Sep 2012 06:04:50 GMT

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.

status changed; resolution set

viboes — Mon, 24 Sep 2012 21:13:43 GMT

status assigned → closed
resolution → fixed

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.

Tue, 25 Sep 2012 13:57:13 GMT

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.