Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Core » Critical section in PteBase::PtrAdd
Critical section in PteBase::PtrAdd [message #45828] Mon, 11 January 2016 12:18 Go to next message
qapko is currently offline  qapko
Messages: 53
Registered: October 2007
Location: Slovakia
Member
Hello,

out of curiosity I have studied the implementation of Ptr template and noticed, that in PteBase::PtrAdd the critical section sPteLock is leaved at the beginning of the else block, just before writing to "prec" and its subitems. Is it OK? If yes, why? At first glance I would suppose, that because of some risk of race condition here, the sPteLock should be leaved at the end of the else block. Am I missing something?

Gabi
Re: Critical section in PteBase::PtrAdd [message #45829 is a reply to message #45828] Mon, 11 January 2016 13:52 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13130
Registered: November 2005
Ultimate Member
qapko wrote on Mon, 11 January 2016 12:18
Hello,

out of curiosity I have studied the implementation of Ptr template and noticed, that in PteBase::PtrAdd the critical section sPteLock is leaved at the beginning of the else block, just before writing to "prec" and its subitems. Is it OK? If yes, why? At first glance I would suppose, that because of some risk of race condition here, the sPteLock should be leaved at the end of the else block. Am I missing something?

Gabi


Hi,

I believe that the original reasoning was:

You should use some other pointee related mutex when taking pointer to pointee, because pointer is R/W and that is why this is a non-const operation. And in that case, it is clear that this is the first pointer and we know (because of external mutex), that no other "first" pointer will race with us. Therefore it is possible and better to release mutex early, as 'new' can be lengthy operation and we are using single mutex for ALL pointers.

Anyway... The optimization is very small and now, years later, I am not sure it is worth risking that above reasoning is correct in all cases... I have changed the code to use the mutex for the whole block.

Thanks,

Mirek

P.S.: Funny. Previous change to that file was 8 years ago... Smile

[Updated on: Mon, 11 January 2016 14:12]

Report message to a moderator

Re: Critical section in PteBase::PtrAdd [message #45832 is a reply to message #45829] Mon, 11 January 2016 15:01 Go to previous message
qapko is currently offline  qapko
Messages: 53
Registered: October 2007
Location: Slovakia
Member
Hello,

your original reasoning makes sense to me. Maybe it would be better not to "fix" it at all Smile

Thanks for your reply.

Gabi
Previous Topic: Print to desired configured printer without dialog
Next Topic: Time in milliseconds
Goto Forum:
  


Current Time: Sun Feb 28 07:33:25 CET 2021

Total time taken to generate the page: 0.01852 seconds