RE: [JBoss-dev] synchronization on non-final fields warning
A given instance of JaasSecurityManager never has its domainCache reset. Its set only on creation of JaasSecurityManager by the JaasSecurityManagerService when a lookup does not have an existing binding. This cannot be seen from the given JaasSecurityManager code fragment though. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Marlow Sent: Thursday, April 20, 2006 6:36 PM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] synchronization on non-final fields warning The problem in the JaasSecurityManager class example below is that the domainCache variable itself needs to be protected with synchronization since its non-final (for all domainCache read/write operations.) It is not fine as one thread could be performing updateCache(Principal), meanwhile, another thread assigns a new value to domainCache. The thread performing updateCache, wouldn't have a consistent memory view of the new domainCache and also violates atomicity. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] synchronization on non-final fields warning
The problem in the JaasSecurityManager class example below is that the
domainCache variable itself needs to be protected with synchronization
since its non-final (for all domainCache read/write operations.)
It is not fine as one thread could be performing updateCache(Principal),
meanwhile, another thread assigns a new value to domainCache. The
thread performing updateCache, wouldn't have a consistent memory view of
the new domainCache and also violates atomicity.
On Tue, 2006-04-11 at 23:51 -0500, Scott M Stark wrote:
I'm trying to understand the full implication of the intellij
synchronization on non-final fields warning, which has this description:
This inspection reports instances of synchronized statements where the
lock expression is a non-final field. Such statements are unlikely to
have useful semantics, as different threads may be locking on different
objects even when operating on the same object.
An example usage is the following where a multiple operations on the
domainCache variable is done in a synchronized block so that the
remove/insert are atomic:
public class JaasSecurityManager
{
private CachePolicy domainCache;
private Subject updateCache(Principal principal)
{
synchronized( domainCache )
{
if( domainCache.peek(principal) != null )
domainCache.remove(principal);
domainCache.insert(principal, info);
}
}
}
In going over the current memory model docs:
http://www.cs.umd.edu/~pugh/java/memoryModel/
http://gee.cs.oswego.edu/dl/jmm/cookbook.html
http://www.cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf
The only context I can see where this warning applies is if the
domainCache variable is being changed. In that case two threads may
actually be synchronizing/working on different objects, but that is fine
in this case as the atomic block of ops only applies to the domainCache
object. If other state was being referenced I can see a problem, but not
for the illustrated usage.
Am I missing something here?
Scott Stark
VP Architecture Technology
JBoss Inc.
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] synchronization on non-final fields warning
Correct, if it did this instead:
public class JaasSecurityManager
{
private CachePolicy domainCache;
private Subject updateCache(Principal principal)
{
synchronized( domainCache )
{
domainCache = new CachePolicy();
// stuff
}
}
}
Another thread can enter the synchronized block
because it will synchronize on a different object.
I'm not sure it is even determinate which
object it will synchronize on under the old
(pre Java5) memory model?
And probably only determinate on Java5 if you do
private volatile CachePolicy domainCache;
On Tue, 2006-04-11 at 23:51 -0500, Scott M Stark wrote:
I'm trying to understand the full implication of the intellij
synchronization on non-final fields warning, which has this description:
This inspection reports instances of synchronized statements where the
lock expression is a non-final field. Such statements are unlikely to
have useful semantics, as different threads may be locking on different
objects even when operating on the same object.
An example usage is the following where a multiple operations on the
domainCache variable is done in a synchronized block so that the
remove/insert are atomic:
public class JaasSecurityManager
{
private CachePolicy domainCache;
private Subject updateCache(Principal principal)
{
synchronized( domainCache )
{
if( domainCache.peek(principal) != null )
domainCache.remove(principal);
domainCache.insert(principal, info);
}
}
}
In going over the current memory model docs:
http://www.cs.umd.edu/~pugh/java/memoryModel/
http://gee.cs.oswego.edu/dl/jmm/cookbook.html
http://www.cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf
The only context I can see where this warning applies is if the
domainCache variable is being changed. In that case two threads may
actually be synchronizing/working on different objects, but that is fine
in this case as the atomic block of ops only applies to the domainCache
object. If other state was being referenced I can see a problem, but not
for the illustrated usage.
Am I missing something here?
Scott Stark
VP Architecture Technology
JBoss Inc.
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Adrian Brock
Chief Scientist
JBoss Inc.
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] synchronization on non-final fields warning
I'm trying to understand the full implication of the intellij
synchronization on non-final fields warning, which has this description:
This inspection reports instances of synchronized statements where the
lock expression is a non-final field. Such statements are unlikely to
have useful semantics, as different threads may be locking on different
objects even when operating on the same object.
An example usage is the following where a multiple operations on the
domainCache variable is done in a synchronized block so that the
remove/insert are atomic:
public class JaasSecurityManager
{
private CachePolicy domainCache;
private Subject updateCache(Principal principal)
{
synchronized( domainCache )
{
if( domainCache.peek(principal) != null )
domainCache.remove(principal);
domainCache.insert(principal, info);
}
}
}
In going over the current memory model docs:
http://www.cs.umd.edu/~pugh/java/memoryModel/
http://gee.cs.oswego.edu/dl/jmm/cookbook.html
http://www.cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf
The only context I can see where this warning applies is if the
domainCache variable is being changed. In that case two threads may
actually be synchronizing/working on different objects, but that is fine
in this case as the atomic block of ops only applies to the domainCache
object. If other state was being referenced I can see a problem, but not
for the illustrated usage.
Am I missing something here?
Scott Stark
VP Architecture Technology
JBoss Inc.
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
