From Jason Turner

[thread.mutex.requirements.mutex]

Diff to HTML by rtfpessoa

tmp/tmpwbqpoebl/{from.md → to.md} RENAMED
@@ -144,13 +144,13 @@ another thread to acquire ownership of that object will fail (for
144
  released ownership with a call to `unlock()`.
145
 
146
  [*Note 4*: After a thread `A` has called `unlock()`, releasing a mutex,
147
  it is possible for another thread `B` to lock the same mutex, observe
148
  that it is no longer in use, unlock it, and destroy it, before thread
149
- `A` appears to have returned from its unlock call. Implementations are
150
- required to handle such scenarios correctly, as long as thread `A`
151
- doesn’t access the mutex after the unlock call returns. These cases
152
  typically occur when a reference-counted object contains a mutex that is
153
  used to protect the reference count. — *end note*]
154
 
155
  The class `mutex` meets all of the mutex requirements
156
  [[thread.mutex.requirements]]. It is a standard-layout class
@@ -206,10 +206,10 @@ ownership for a `recursive_mutex` object, additional calls to
206
  of type `system_error`. A thread shall call `unlock()` once for each
207
  level of ownership acquired by calls to `lock()` and `try_lock()`. Only
208
  when all levels of ownership have been released may ownership be
209
  acquired by another thread.
210
 
211
- The behavior of a program is undefined if:
212
 
213
  - it destroys a `recursive_mutex` object owned by any thread or
214
  - a thread terminates while owning a `recursive_mutex` object.
215
 
 
144
  released ownership with a call to `unlock()`.
145
 
146
  [*Note 4*: After a thread `A` has called `unlock()`, releasing a mutex,
147
  it is possible for another thread `B` to lock the same mutex, observe
148
  that it is no longer in use, unlock it, and destroy it, before thread
149
+ `A` appears to have returned from its unlock call. Conforming
150
+ implementations handle such scenarios correctly, as long as thread `A`
151
+ does not access the mutex after the unlock call returns. These cases
152
  typically occur when a reference-counted object contains a mutex that is
153
  used to protect the reference count. — *end note*]
154
 
155
  The class `mutex` meets all of the mutex requirements
156
  [[thread.mutex.requirements]]. It is a standard-layout class
 
206
  of type `system_error`. A thread shall call `unlock()` once for each
207
  level of ownership acquired by calls to `lock()` and `try_lock()`. Only
208
  when all levels of ownership have been released may ownership be
209
  acquired by another thread.
210
 
211
+ The behavior of a program is undefined if
212
 
213
  - it destroys a `recursive_mutex` object owned by any thread or
214
  - a thread terminates while owning a `recursive_mutex` object.
215