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

Benedict commented on CASSANDRA-7705:
-------------------------------------

I have updated the repository with a rebased version, with some improved 
comments and a debug mode. 

This is essentially free given java's object alignment behaviour and run time 
optimisation (the field doesn't occupy any memory we wouldn't otherwise be 
occupying, and the relevant statements will be optimised away).

> Safer Resource Management
> -------------------------
>
>                 Key: CASSANDRA-7705
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7705
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>            Assignee: Benedict
>             Fix For: 3.0
>
>
> We've had a spate of bugs recently with bad reference counting. these can 
> have potentially dire consequences, generally either randomly deleting data 
> or giving us infinite loops. 
> Since in 2.1 we only reference count resources that are relatively expensive 
> and infrequently managed (or in places where this safety is probably not as 
> necessary, e.g. SerializingCache), we could without any negative consequences 
> (and only slight code complexity) introduce a safer resource management 
> scheme for these more expensive/infrequent actions.
> Basically, I propose when we want to acquire a resource we allocate an object 
> that manages the reference. This can only be released once; if it is released 
> twice, we fail immediately at the second release, reporting where the bug is 
> (rather than letting it continue fine until the next correct release corrupts 
> the count). The reference counter remains the same, but we obtain guarantees 
> that the reference count itself is never badly maintained, although code 
> using it could mistakenly release its own handle early (typically this is 
> only an issue when cleaning up after a failure, in which case under the new 
> scheme this would be an innocuous error)



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

Reply via email to