I am on the road so not able to be most timely. The issue is that
there is a class level lock applied when a thead instance is created
with a subclass of thread. Look at the constructors got the details.
Gregg Wonderly
Sent from my iPhone
On Jun 4, 2010, at 11:02 PM, Peter Firmstone <[email protected]> wrote:
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
