Quantcast

ReentrantReadWriteLock sample usage - redundant volatile

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ReentrantReadWriteLock sample usage - redundant volatile

Roman Leventov
It seems that in "CachedData" sample usage in ReentrantReadWriteLock class-level Javadoc comment volatile on cacheValid field is redundant, because cacheValid is only accessed when readLock or writeLock is held, that should guarantee total memory safety.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ReentrantReadWriteLock sample usage - redundant volatile

Doug Lea
On 12/12/2016 03:55 PM, Roman Leventov wrote:
> It seems that in "CachedData" sample usage in ReentrantReadWriteLock
> class-level Javadoc comment volatile on cacheValid field is redundant,
> because cacheValid is only accessed when readLock or writeLock is held,
> that should guarantee total memory safety.
>

Thanks; changed. Omitting "volatile" here might reduce confusion.
My vague recollection is that the example was abstracted from
an actual usage, where there may have been some reason to rely on
volatile in other parts of the code.

-Doug


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ReentrantReadWriteLock sample usage - redundant volatile

Jörg Hettel

In this case cacheValid field should also be changed to private

Joerg


Am 13.12.2016 um 22:08 schrieb Doug Lea:
On 12/12/2016 03:55 PM, Roman Leventov wrote:
It seems that in "CachedData" sample usage in ReentrantReadWriteLock
class-level Javadoc comment volatile on cacheValid field is redundant,
because cacheValid is only accessed when readLock or writeLock is held,
that should guarantee total memory safety.


Thanks; changed. Omitting "volatile" here might reduce confusion.
My vague recollection is that the example was abstracted from
an actual usage, where there may have been some reason to rely on
volatile in other parts of the code.

-Doug


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Loading...