Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Posted by R.J. Lorimer on Jul 13, 2008
Doug Lea, the spec lead of the JSR 166 concurrency utilities, posted on the 166y concurrency-interest mailing list this week regarding a new feature being introduced into JSR-166y: Phasers.The flexible barrier functionality that was previously restricted to ForkJoinTasks (in class forkjoin.TaskBarrier) is being redone as class Phaser (targeted for j.u.c, not j.u.c.forkjoin), that can be applied in all kinds of tasks.The 'Phaser' concept and name was coined in this whitepaper by a team at Rice University. The name comes from the construct's phase-ordering and deadlock-avoidance properties. The whitepaper explains several details of the phaser concept. When comparing phasers to existing Java features, it is explained that similar functionality to the CyclicBarrier class is supported (introduced in Java 5), but phasers are inherently more flexible:
The [java.util.concurrent] CyclicBarrier class supports periodic barrier synchronization among a set of threads. Unlike Phasers, however, CyclicBarriers do not support the dynamic addition or removal of threads; nor do they support one-way synchronization or split-phase operation.One of the main motivators for exploring additional barrier implementations was not just to have increased flexibility, but also to increase performance and scalability of the barrier synchronization concept:
Performance results obtained from a portable implementation of phasers on three different SMP platforms demonstrate that they can deliver superior performance to existing barrier implementations, in addition to the productivity benefits that result from their generality and safety properties.As mentioned by Doug Lea, the implementation of Phaser for JSR-166y is being adapted from facilities in the existing fork/join framework implementation. The fork/join framework is something that InfoQ has covered before on multiple occasions, and is one of the central features in the upcoming 166y JSR - it is also the subject of a whitepaper by Doug Lea that describes the purpose and usage of the framework. The TaskBarrier class mentioned above was used by the fork/join framework to manage the boundaries between the various tasks, and merge their results; in other words: to join the tasks.
Comments and suggestions are very welcome as always. The API is likely to change a bit as we scope out further uses, and also, hopefully, stumble upon some better method names.It is currently expected that JSR-166y will be included as part of Java 7.
Consolidation and Virtualization Are NOT Enough: The Case for Non-x86
Innovation in Your Data Centre
The 5 Mandates of Software Development Teams - Presto Manifesto
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
No comments
Watch Thread Reply