You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Ariel Weisberg (JIRA)" <ji...@apache.org> on 2014/12/04 16:59:12 UTC

[jira] [Commented] (CASSANDRA-7705) Safer Resource Management

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

Ariel Weisberg commented on CASSANDRA-7705:
-------------------------------------------

I didn't review I just read through because it looked interesting.

Maybe not a good fit here, but one of things I found useful in a smart pointer/container was to use conditional compilation to support a debug build where the stack of the allocator, deallocator, and mistaken extra deallocation were all stored in the reference so it was a little easier to debug because errors could log that information. You could store the thread name as well.

If references are not always shared AKA wrapper references does it make sense to have a wrapper report an error if it is released twice?

Is using reference queues any better than just using finalization?

AstractRefCounted.State.refs appears to be unused?

Out of scope for this ticket, but are there resources requiring deallocation that don't use reference counting or that are very high traffic (once or more per request?). 



> 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)