[jboss-jira] [JBoss JIRA] (JGRP-1822) LockService.LockImpl synchronization issue with AtomicReference<Thread> holder

[Manuel Dominguez Sarmiento (JIRA)]

     [ https://issues.jboss.org/browse/JGRP-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Manuel Dominguez Sarmiento updated JGRP-1822:
---------------------------------------------

    Description: 
Right now, if two different threads invoke LockImpl.tryLock() on the same LockImpl instance, only one of them will obtain the lock, however both will attempt to update the AtomicReference<Thread> holder. Therefore the LockImpl may be left with a null holder value, even if the lock is actually held by another thread.

Similar issues might occur with the other methods (lock(), lockInterruptibly(), etc)

This can be worked around by obtaining new LockImpl instances on every use. In our use case we were caching the LockImpl instances for each lock name, so that's why we came across this.

  was:
Right now, if two different threads invoke LockImpl.tryLock(), only one of them will obtain the lock, however both will attempt to update the AtomicReference<Thread> holder. Therefore the LockImpl may be left with a null holder value, even if the lock is actually held by another thread.

Similar issues might occur with the other methods (lock(), lockInterruptibly(), etc)

This can be worked around by obtaining new LockImpl instances on every use. In our use case we were caching the LockImpl instances for each lock name, so that's why we came across this.


    
> LockService.LockImpl synchronization issue with AtomicReference<Thread> holder
> ------------------------------------------------------------------------------
>
>                 Key: JGRP-1822
>                 URL: https://issues.jboss.org/browse/JGRP-1822
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4.2
>            Reporter: Manuel Dominguez Sarmiento
>            Assignee: Bela Ban
>
> Right now, if two different threads invoke LockImpl.tryLock() on the same LockImpl instance, only one of them will obtain the lock, however both will attempt to update the AtomicReference<Thread> holder. Therefore the LockImpl may be left with a null holder value, even if the lock is actually held by another thread.
> Similar issues might occur with the other methods (lock(), lockInterruptibly(), etc)
> This can be worked around by obtaining new LockImpl instances on every use. In our use case we were caching the LockImpl instances for each lock name, so that's why we came across this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira