Skip to content

Commit

Permalink
Merge pull request #447 from m-ou-se/synchapi-no-destroy
Browse files Browse the repository at this point in the history
Clarify destruction of SRW locks and condition variables.
Karl-Bridge-Microsoft authored Sep 14, 2020

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
2 parents ec20452 + 722cbf5 commit 9056434
Showing 2 changed files with 4 additions and 3 deletions.
Original file line number Diff line number Diff line change
@@ -70,8 +70,9 @@ Threads can atomically release a lock and enter the sleeping state using the <a

Condition variables are user-mode objects that cannot be shared across processes.

A condition variable cannot be moved or copied. The process must not modify the object, and must instead treat it as logically opaque. Only use the condition variable functions to manage condition variables.
A condition variable cannot be moved or copied while in use. The process must not modify the object, and must instead treat it as logically opaque. Only use the condition variable functions to manage condition variables.

A condition variable with no waiting threads is in its initial state and can be copied, moved, and forgotten without being explicitly destroyed.

#### Examples

4 changes: 2 additions & 2 deletions sdk-api-src/content/synchapi/nf-synchapi-initializesrwlock.md
Original file line number Diff line number Diff line change
@@ -68,9 +68,9 @@ A pointer to the SRW lock.

An SRW lock must be initialized before it is used. The InitializeSRWLock function is used to initialize a SRW lock dynamically. To initialize the structure statically, assign the constant <b>SRWLOCK_INIT</b> to the structure variable.

An SRW lock cannot be moved or copied. The process must not modify the object, and must instead treat it as logically opaque. Only use the SRW functions to manage SRW locks.
An SRW lock cannot be moved or copied while in use. The process must not modify the object, and must instead treat it as logically opaque. Only use the SRW functions to manage SRW locks.

SRW locks do not need to be explicitly destroyed.
An unlocked SRW lock with no waiting threads is in its initial state and can be copied, moved, and forgotten without being explicitly destroyed.

## -see-also

0 comments on commit 9056434

Please sign in to comment.