U++ forum: Welcome to the forum

Search on this site

Search in forums

Home » U++ Library support » U++ Core » Critical section in PteBase::PtrAdd

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Critical section in PteBase::PtrAdd [message #45828]

Mon, 11 January 2016 12:18

qapko
Messages: 55
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

Report message to a moderator

Re: Critical section in PteBase::PtrAdd [message #45829 is a reply to message #45828]

Mon, 11 January 2016 13:52

mirek
Messages: 13975
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