You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "David Jencks (JIRA)" <je...@portals.apache.org> on 2005/12/29 04:16:02 UTC
[jira] Created: (JS2-457) JetspeedPipeline synchronization is broken and using a threadlocal is really ugly
JetspeedPipeline synchronization is broken and using a threadlocal is really ugly
---------------------------------------------------------------------------------
Key: JS2-457
URL: http://issues.apache.org/jira/browse/JS2-457
Project: Jetspeed 2
Type: Bug
Components: Container
Reporter: David Jencks
I previously addressed these issues in J2-115 and still think that is a better solution. Here is a way to remove use of a threadlocal to track a call's progress through the valves that does not change any classes or configuration other than JetspeedPipeline.
In addition, the synchronization in JetspeedPipeline is fairly useless. Some problems include:
suppose 2 calls come simultaneously and block on valves1. The first call changes valves to point to valves2. While the second call is changing valves2 to valves3, while locking valves1, a third call comes in, finds valves2 unlocked, and changes valves2 to vavles4. The result might be valves3 or valves4, but won't have both changes.
Also, the access to valves while traversing the pipeline needs to be synchronized, or there is no guarantee that a completely written vavle array will be accessed: according to arguments made around "double checked locking is broken", the JIT can rearrange code so that the "valves" variable can be set before the array is filled in.
I believe all the synchronization can be removed if the addValve and removeValve methods are eliminated. I personally think this would be a good idea.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-457) JetspeedPipeline synchronization is broken and using a threadlocal is really ugly
Posted by "David Sean Taylor (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-457?page=comments#action_12361453 ]
David Sean Taylor commented on JS2-457:
---------------------------------------
Still -1 on J2-115 as I believe, although it would work fine, it is without style, ignoring the merit of the J2 architecture. Really ugly patch.
However, Im willing to give JS2-457 and I do agree the synchronization and thread locals should go. I never had a problem with changing the implementation, only the abstraction and concepts.
> JetspeedPipeline synchronization is broken and using a threadlocal is really ugly
> ---------------------------------------------------------------------------------
>
> Key: JS2-457
> URL: http://issues.apache.org/jira/browse/JS2-457
> Project: Jetspeed 2
> Type: Bug
> Components: Container
> Reporter: David Jencks
> Attachments: pipeline.diff
>
> I previously addressed these issues in J2-115 and still think that is a better solution. Here is a way to remove use of a threadlocal to track a call's progress through the valves that does not change any classes or configuration other than JetspeedPipeline.
> In addition, the synchronization in JetspeedPipeline is fairly useless. Some problems include:
> suppose 2 calls come simultaneously and block on valves1. The first call changes valves to point to valves2. While the second call is changing valves2 to valves3, while locking valves1, a third call comes in, finds valves2 unlocked, and changes valves2 to vavles4. The result might be valves3 or valves4, but won't have both changes.
> Also, the access to valves while traversing the pipeline needs to be synchronized, or there is no guarantee that a completely written vavle array will be accessed: according to arguments made around "double checked locking is broken", the JIT can rearrange code so that the "valves" variable can be set before the array is filled in.
> I believe all the synchronization can be removed if the addValve and removeValve methods are eliminated. I personally think this would be a good idea.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Resolved: (JS2-457) JetspeedPipeline synchronization is broken and using a threadlocal is really ugly
Posted by "David Sean Taylor (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-457?page=all ]
David Sean Taylor resolved JS2-457:
-----------------------------------
Resolution: Fixed
patch applied
> JetspeedPipeline synchronization is broken and using a threadlocal is really ugly
> ---------------------------------------------------------------------------------
>
> Key: JS2-457
> URL: http://issues.apache.org/jira/browse/JS2-457
> Project: Jetspeed 2
> Type: Bug
> Components: Container
> Reporter: David Jencks
> Assignee: David Sean Taylor
> Attachments: pipeline.diff
>
> I previously addressed these issues in J2-115 and still think that is a better solution. Here is a way to remove use of a threadlocal to track a call's progress through the valves that does not change any classes or configuration other than JetspeedPipeline.
> In addition, the synchronization in JetspeedPipeline is fairly useless. Some problems include:
> suppose 2 calls come simultaneously and block on valves1. The first call changes valves to point to valves2. While the second call is changing valves2 to valves3, while locking valves1, a third call comes in, finds valves2 unlocked, and changes valves2 to vavles4. The result might be valves3 or valves4, but won't have both changes.
> Also, the access to valves while traversing the pipeline needs to be synchronized, or there is no guarantee that a completely written vavle array will be accessed: according to arguments made around "double checked locking is broken", the JIT can rearrange code so that the "valves" variable can be set before the array is filled in.
> I believe all the synchronization can be removed if the addValve and removeValve methods are eliminated. I personally think this would be a good idea.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Updated: (JS2-457) JetspeedPipeline synchronization is broken and using a threadlocal is really ugly
Posted by "David Jencks (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-457?page=all ]
David Jencks updated JS2-457:
-----------------------------
Attachment: pipeline.diff
> JetspeedPipeline synchronization is broken and using a threadlocal is really ugly
> ---------------------------------------------------------------------------------
>
> Key: JS2-457
> URL: http://issues.apache.org/jira/browse/JS2-457
> Project: Jetspeed 2
> Type: Bug
> Components: Container
> Reporter: David Jencks
> Attachments: pipeline.diff
>
> I previously addressed these issues in J2-115 and still think that is a better solution. Here is a way to remove use of a threadlocal to track a call's progress through the valves that does not change any classes or configuration other than JetspeedPipeline.
> In addition, the synchronization in JetspeedPipeline is fairly useless. Some problems include:
> suppose 2 calls come simultaneously and block on valves1. The first call changes valves to point to valves2. While the second call is changing valves2 to valves3, while locking valves1, a third call comes in, finds valves2 unlocked, and changes valves2 to vavles4. The result might be valves3 or valves4, but won't have both changes.
> Also, the access to valves while traversing the pipeline needs to be synchronized, or there is no guarantee that a completely written vavle array will be accessed: according to arguments made around "double checked locking is broken", the JIT can rearrange code so that the "valves" variable can be set before the array is filled in.
> I believe all the synchronization can be removed if the addValve and removeValve methods are eliminated. I personally think this would be a good idea.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Assigned: (JS2-457) JetspeedPipeline synchronization is broken and using a threadlocal is really ugly
Posted by "David Sean Taylor (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-457?page=all ]
David Sean Taylor reassigned JS2-457:
-------------------------------------
Assign To: David Sean Taylor
> JetspeedPipeline synchronization is broken and using a threadlocal is really ugly
> ---------------------------------------------------------------------------------
>
> Key: JS2-457
> URL: http://issues.apache.org/jira/browse/JS2-457
> Project: Jetspeed 2
> Type: Bug
> Components: Container
> Reporter: David Jencks
> Assignee: David Sean Taylor
> Attachments: pipeline.diff
>
> I previously addressed these issues in J2-115 and still think that is a better solution. Here is a way to remove use of a threadlocal to track a call's progress through the valves that does not change any classes or configuration other than JetspeedPipeline.
> In addition, the synchronization in JetspeedPipeline is fairly useless. Some problems include:
> suppose 2 calls come simultaneously and block on valves1. The first call changes valves to point to valves2. While the second call is changing valves2 to valves3, while locking valves1, a third call comes in, finds valves2 unlocked, and changes valves2 to vavles4. The result might be valves3 or valves4, but won't have both changes.
> Also, the access to valves while traversing the pipeline needs to be synchronized, or there is no guarantee that a completely written vavle array will be accessed: according to arguments made around "double checked locking is broken", the JIT can rearrange code so that the "valves" variable can be set before the array is filled in.
> I believe all the synchronization can be removed if the addValve and removeValve methods are eliminated. I personally think this would be a good idea.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org