river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: com.sun.jini.thread lock contention
Date Sat, 05 Jun 2010 03:02:47 GMT
Hi Gregg,

The contention appears to be around the use of the existing single 
thread synchronized Policy implementations like DynamicPolicyProvider.

There are numerous places where Thread is checked (not just subclasses) 
by the SecurityManager using the checkAccess(Thread) method, this is 
delegated to AccessController.checkPermission(perm)

checkPermission(perm) gets the AccessControlContext of the currently 
executing stack, AccessControlContext.optimize() is called to remove 
duplicate PermissionDomain's

then AccessControlContext.checkPermission(perm) is called to check the 
permission's of all the ProtectionDomain's on the current stack, the 
ProtectionDomain's on the stack are iterated through, the first 
ProtectionDomain.implies(Permission) that returns false returns causes 
the AccessControlContext to return false.

This means that if your thread is executing with several CodeSource's it 
will have to check several ProtectionDomains.

Each ProtectionDomain will check the policy, if the ProtectionDomain was 
created with the dynamic policy domain constructor:

public ProtectionDomain(CodeSource codesource,
                PermissionCollection permissions,
                ClassLoader classloader,
                Principal[] principals)

The ProtectionDomain first check's the Policy for the permission, then 
it checks it's own private PermissionCollection permissions passed in 
via the constructor, or that which has been merged with the permissions 
from the Policy. 

Policy.getPermissions(ProtectionDomain)

In my RevokeablePolicy implementation, getPermissions doesn't return any 
dynamic Permission grant's, if it did, they could never be revoked as 
they would become merged with the ProtectionDomains private 
PermissionCollection.

So to sum up, you should get much better mileage if you try out my new 
ConcurrentDynamicPolicy implementation.

I know you've got a privately forked copy of River, but if you simply 
copy concurrent_policy_utils.jar and jsk-policy.jar from River's Hudson 
build, to your jre/lib/ext directory, you should be able to utilise it.

The ConcurrentDynanicPolicyProvider has passed all qa tests and jtreg 
tests, I'm just waiting for someone like yourself to report back 
concurrency improvements.

Cheers,

Peter.


Gregg Wonderly wrote:
> The TaskManager class has a subclass of Thread that it uses to run 
> tasks.  The problem with subclassing Thread, is that there is a lock 
> that is used in Thread to see if some methods are overridden so that 
> security can be maintained.  So, in an environment where Thread is 
> used with a SecurityManager, it is better to use a Runnable to 
> encapsulate the custom code, instead of a Thread.
>
> The TaskThread class should be a Runnable instead of a Thread, and 
> then there are just 3 other places where it is referenced that need 
> some adjustment.  The thread that is running inside of the runnable 
> needs to be put into a per instance variable for one place where 
> interrupt processing is handled.
>
> Gregg Wonderly
>


Mime
View raw message