cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Hodges (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-734) Table.open has a broken lock in it
Date Mon, 25 Jan 2010 02:56:34 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804351#action_12804351
] 

Jeff Hodges commented on CASSANDRA-734:
---------------------------------------

bq. It doesn't: it solves the problem of doing get() on a thread-unsafe object while remaining
high performance. I'm saying, we can use Table.open in close to its current form by replacing
the current HashMap w/ a NBHM, and continuing to use a synchronized block for if the get()
is null. 

You've forgotten about instantiating the Table twice. One thread notices that the get is null
and in another thread the same happens before the first thread manages to do a put.

> Table.open has a broken lock in it
> ----------------------------------
>
>                 Key: CASSANDRA-734
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-734
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: 0.5
>            Reporter: Jeff Hodges
>            Assignee: Jeff Hodges
>            Priority: Minor
>             Fix For: 0.6
>
>         Attachments: broken_lock_in_table_open.patch
>
>
> Table.open's lock is used around the Map#put method call but not the #get. This makes
it a source of spurious bugs. The attached patch synchronizes the entire Table.open method
and removes the unused createLock static.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message