Inconsistent locking in Debug and Release mode

michael.proepster's Avatar

michael.proepster

19 Sep, 2017 11:56 AM

We are using ReaderWriterSynchronized aspect.
Consider this code:

    [ExplicitlySynchronized]
    public void ExplicitlySynchronizedThenRead()
    {
        Read();
    }
    [Reader]
    public string Read()
    {
        ...
    }

When I call ExplicitlySynchronizedThenRead() in Debug mode, the Read method executes without acquiring any lock. Is that correct?
In Release mode, the Read method does acquire the Reader lock. Is that correct?

If yes, do you agree that this inconsistent behaviour can lead to deadlocks in Release mode that cannot be reproduced and debugged in Debug mode?
Do you agree that this can lead to incorrectly synchronized code in Debug mode, while in Release mode it works perfectly?

Thanks
Michael

  1. Support Staff 1 Posted by PostSharp Techn... on 20 Sep, 2017 10:59 AM

    PostSharp Technologies's Avatar

    Hello,

    this is a bug and it is caused by [ExplicitlySynchronized] transformation relying upon RuntimeVerificationEnabled property, default value of which is dependent on build property PostSharpRuntimeVerificationEnabled (which in turn depends on Optimize MSBuild property). This is not correct as [ExplicitlySynchronized] changes behavior of subsequent calls to methods that are regularly synchronized. I couldn't find when this bug was introduced, but it was missed by our tests.

    Until we fix this, please either explicitly set PostSharpRuntimeVerificationEnabled MSBuild property in your project files, RuntimeVerificationEnabled PostSharp property in PostSharp configuration file (which can be more convenient if you have many projects), or RuntimeVerificationEnabled property on the individual aspect.

    (issue #15515)

    Best regards,
    Daniel

  2. Support Staff 2 Posted by PostSharp Techn... on 02 Oct, 2017 03:29 PM

    PostSharp Technologies's Avatar

    Hello,

    We're closing the ticket for now as the bug has been internally filed as issue #15515. We will contact you as soon as the bug fix has been released.

    For more details on our support policies and prioritization of bug fixes, please visit https://www.postsharp.net/support/policies

    Thanks,
    PostSharp Team

  3. PostSharp Technologies closed this discussion on 02 Oct, 2017 03:29 PM.

  4. PostSharp Technologies re-opened this discussion on 20 Nov, 2017 09:45 AM

  5. Support Staff 3 Posted by PostSharp Techn... on 20 Nov, 2017 09:45 AM

    PostSharp Technologies's Avatar

    Hello,

    The bug #15515 has been fixed in the current versions of PostSharp 4.3.40 and 5.0.38.
    Should you need further help with this issue, don't hesitate to re-open this discussion.

    -alex

  6. PostSharp Technologies closed this discussion on 20 Nov, 2017 09:45 AM.

  7. michael.proepster re-opened this discussion on 01 Dec, 2017 09:36 AM

  8. 4 Posted by michael.proepst... on 01 Dec, 2017 09:36 AM

    michael.proepster's Avatar

    What have you changed? What is the new behaviour?
    As I understand it, [ExplicitlySynchronized] does no longer rely upon RuntimeVerificationEnabled. But what is now the behaviour?
    Does the Read method in my example aquire a lock or not?

  9. Support Staff 5 Posted by PostSharp Techn... on 01 Dec, 2017 10:26 AM

    PostSharp Technologies's Avatar

    Hello,

    First, [ExplicitlySynchronized] does not depend upon the RuntimeVerificationEnabled property.

    Second, in the given example the lock is not acquired by the Read method. The correct behavior is that [ExplicitlySynchronized] opens a context for unchecked access level and it's up to the user to make sure the code is synchronized correctly within this context.

    -alex

  10. Support Staff 6 Posted by PostSharp Techn... on 13 Dec, 2017 02:53 PM

    PostSharp Technologies's Avatar

    Hello,

    We are going to close this request as there have not been any further updates. Please feel free to reopen the discussion if you need more help.

    Thanks,
    PostSharp Team

  11. PostSharp Technologies closed this discussion on 13 Dec, 2017 02:53 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac