You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@stanbol.apache.org by "Rafa Haro (JIRA)" <ji...@apache.org> on 2015/07/04 01:11:04 UTC

[jira] [Closed] (STANBOL-653) Use native java locks in commons-owl JenaToOwlConvert

     [ https://issues.apache.org/jira/browse/STANBOL-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rafa Haro closed STANBOL-653.
-----------------------------
    Resolution: Pending Closed

> Use native java locks in commons-owl JenaToOwlConvert
> -----------------------------------------------------
>
>                 Key: STANBOL-653
>                 URL: https://issues.apache.org/jira/browse/STANBOL-653
>             Project: Stanbol
>          Issue Type: Bug
>          Components: Commons
>            Reporter: Peter Ansell
>
> The JenaToOwlConvert transforming class in commons/owl currently uses while loops along with two variables to track entrances and exits from all of the methods. In addition to the broken semantics of using a while loop with a non-volatile variable and non-atomic getAndSet operation, there are currently no "unlocks" in finally or catch blocks, so if exceptions are thrown the "lock" may never be released, and the use of non-volatile variables with non-atomic getAndSet operations means that many threads may get through each time the variable changes.
> I am not familiar with the class or its context, so I do not know why the current system was implemented, and if the locks are even necessary. However, if they are necessary they should be implemented using native java locks and finally blocks to ensure that in every case the locks are released. If they are not necessary it is should be easy to remove them and turn the class into a multi-threadable class, with users arranging synchronisation where necessary.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)