#3346 closed defect (invalid)
implementation check for "RTLock::release"
| Reported by: | Markus Elfring | Owned by: | |
|---|---|---|---|
| Component: | other | Version: | VirtualBox 2.1.2 |
| Keywords: | mutual exclusion, concurrency | Cc: | |
| Guest type: | other | Host type: | other |
Description
I wonder why the assignment to the variable "mfLocked" is performed without mutual exclusion in the implementation of the member function "RTLock::release". It seems that the instruction is one line too late.
Attachments (1)
Change History (3)
by , 15 years ago
comment:1 by , 15 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
The order does not matter here. Note that an RTLock object is usually stack-local and therefore thread-local. Therefore there is no race accessing the mfLocked variable. The mutex does not guard that variable but the whole code section between RTLock::RTLock() and RTLock::~RTLock()/RTLock::release().
comment:2 by , 15 years ago
I guess that it would still be safer to move the assignment for the variable "mfLocked" into the previous lock scope.
Note:
See TracTickets
for help on using tickets.
update suggestion