On Wed, Jun 6, 2012 at 5:37 PM, Cezary Biernacki <cezary...@gmail.com> wrote:
> On Thu, Jun 7, 2012 at 1:27 AM, Howard Lewis Ship <hls...@gmail.com> wrote:
>
>> You can even omit synchronized and volatile IFF:
>> - only a single shared field is updated
>> - it is ok for a race condition to exist that would create the value
>> on multiple threads
>> - (I learned this by getting schooled on the subject by Rich Hickey)
>>
>> There are many things in Tapestry that don't fit this model.
>> Sometimes the value being lazily created is so expensive, it would be
>> invalid to allow multiple threads to create it. In other cases, more
>> than one shared field is updated.
>>
>
>
> Hm, but the second check inside 'synchronized' block is supposed to avoid
> creating value on multiple threads. For example:
>
> private volatile Messages messages;
>
> public Messages getMessages()
> {
> if (messages != null)
> {
> return messages;
> }
>
> synchronized (this) {
> if (messages != null)
> {
> return messages;
> }
>
> messages = elementResources.getMessages(componentModel);
> // <--- only called if no other thread did this before
> }
>
> return messages;
> }
>
>
>
After review, in this one specific case, I've removed the concurrency
code; the change to the messages field is individual and atomic, and
the value from the elementResources.getMessages() method is cached by
the eventual service implementation.
>
> Cezary
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
