This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of LEWG status.

### 1493. Add `mutex`, `recursive_mutex`, `is_locked` function

Section: 33.6.4 [thread.mutex.requirements] Status: LEWG Submitter: INCITS Opened: 2010-08-25 Last modified: 2017-03-01

Priority: Not Prioritized

View other active issues in [thread.mutex.requirements].

View all other issues in [thread.mutex.requirements].

View all issues with LEWG status.

Discussion:

Addresses US-189

`mutex` and `recursive_mutex` should have an `is_locked()` member function. `is_locked` allows a user to test a lock without acquiring it and can be used to implement a lightweight `try_try_lock`.

[ Resolution proposed by ballot comment: ]

> Add a member function:

>     bool is_locked() const;

> to `std::mutex` and `std::recursive_mutex`. These functions return true if the current thread would not be able to obtain a mutex. These functions do not synchronize with anything (and, thus, can avoid a memory fence).

[ 2010 Batavia ]

The Concurrency subgroup reviewed this issue and deemed it to be an extension to be handled after publishing C++0x.

Rationale:

The LWG does not wish to make a change at this time.

[2017-03-01, Kona]

SG1 recommends: Close as NAD

Several participants voiced strong objections, based on either memory model issues or lock elision. No support. It is already possible to write a wrapper that explicitly tracks ownership for testing in the owning thread, which may have been part of the intent here.

Proposed resolution: