In 30.4.1.2.2 Class recursive_mutex [thread.mutex.recursive]

try_lock is declared as noexcept

   bool try_lock() noexcept;

but 30.4.1.2.1 Class mutex declare it without noexcept
   bool try_lock();

The same applies for timed_mutex and recursive_timed_mutex.

Shouldn't both be coherent. When could try_lock throw an exception?

Vicente


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 2012-01-01 22:26:47 +0000, viboes said:

>  In 30.4.1.2.2 Class recursive_mutex [thread.mutex.recursive]
>
>  try_lock is declared as noexcept
>
>     bool try_lock() noexcept;
>
>  but 30.4.1.2.1 Class mutex declare it without noexcept
>     bool try_lock();
>
>  The same applies for timed_mutex and recursive_timed_mutex.
>
>  Shouldn't both be coherent. When could try_lock throw an exception?
>

If the mutex is already owned by the calling thread, the behavior of a
call to try_lock() is undefined. One possibility is to throw an
exception. For a recursive mutex, the behavior is well defined.

--
  Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

[ Moderator's note: The posting 'bot was down for a few days. -sdc ]


Pete Becker wrote:
>
>  On 2012-01-01 22:26:47 +0000, viboes said:
>
>  >   In 30.4.1.2.2        Class recursive_mutex   [thread.mutex.recursive]
>  >
>  >   try_lock is declared as noexcept
>  >
>  >      bool try_lock() noexcept;
>  >
>  >   but 30.4.1.2.1       Class mutex declare it without noexcept
>  >      bool try_lock();
>  >
>  >   The same applies for timed_mutex and recursive_timed_mutex.
>  >
>  >   Shouldn't both be coherent. When could try_lock throw an exception?
>  >
>
>  If the mutex is already owned by the calling thread, the behavior of a
>  call to try_lock() is undefined. One possibility is to throw an
>  exception. For a recursive mutex, the behavior is well defined.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html

"ERRORS

The pthread_mutex_lock() and pthread_mutex_trylock() functions shall
fail if:

[EAGAIN]

The mutex could not be acquired because the maximum number of recursive
locks for mutex has been exceeded."

How is that error is supposed to be reported with bool try_lock()
noexcept given that false bool reflects

"The pthread_mutex_trylock() function shall fail if:

[EBUSY]

The mutex could not be acquired because it was already locked. "

<?>

regards,
alexander.



--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Am 11.01.2012 18:58, schrieb Alexander Terekhov:
>  Pete Becker wrote:
>>
>>    On 2012-01-01 22:26:47 +0000, viboes said:
>>
>>    >     In 30.4.1.2.2        Class recursive_mutex   [thread.mutex.recursive]
>>    >
>>    >     try_lock is declared as noexcept
>>    >
>>    >        bool try_lock() noexcept;
>>    >
>>    >     but 30.4.1.2.1       Class mutex declare it without noexcept
>>    >        bool try_lock();
>>    >
>>    >     The same applies for timed_mutex and recursive_timed_mutex.
>>    >
>>    >     Shouldn't both be coherent. When could try_lock throw an exception?
>>    >
>>
>>    If the mutex is already owned by the calling thread, the behavior of a
>>    call to try_lock() is undefined. One possibility is to throw an
>>    exception. For a recursive mutex, the behavior is well defined.
>
>  http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html
>
>  "ERRORS
>
>  The pthread_mutex_lock() and pthread_mutex_trylock() functions shall
>  fail if:
>
>  [EAGAIN]
>
>  The mutex could not be acquired because the maximum number of recursive
>  locks for mutex has been exceeded."
>
>  How is that error is supposed to be reported with bool try_lock()
>  noexcept given that false bool reflects
>
>  "The pthread_mutex_trylock() function shall fail if:
>
>  [EBUSY]
>
>  The mutex could not be acquired because it was already locked. "
>
>  <?>

The C++ Library does not describe these situations as failing
requirements of a recursive mutex:

1) [thread.mutex.requirements.mutex] and in particular p15 basically
have the effect that try_lock has no pre-condition for a
std::recursive_mutex and std::recursive_timed_mutex

2) [thread.mutex.recursive] p3 is more specific:

"If a thread has already acquired the maximum level of ownership for a
recursive_mutex object, additional calls to try_lock() shall fail, and
additional calls to lock() shall throw an exception of type
system_error."

It seems that this was a deliberate design choice.

Greetings from Bremen,

Daniel Kr   gler


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]