[concurrency-interest] Cloning in CachingFactorizer in JavaConcurrency in Practice

David Holmes dcholmes at optusnet.com.au
Wed Jan 23 00:17:01 EST 2008


The immediate receiver is encodeIntoResponse, which is called in the same
thread. We don't know how it does what it does, or what other code gets
involved. Ultimately the array may end up being accessed by another thread,
but the defensive copying is done to protect against the code that can
access the array, not the thread.

Put another way, if we trusted all the code that could access the array,
then given these array contents are immutable once set, there would be no
need for cloning, no matter how many threads were involved.

Cheers,
David Holmes
  -----Original Message-----
  From: Unmesh joshi [mailto:unmesh_joshi at hotmail.com]
  Sent: Wednesday, 23 January 2008 3:10 PM
  To: dholmes at ieee.org; concurrency-interest at cs.oswego.edu
  Subject: RE: [concurrency-interest] Cloning in CachingFactorizer in
JavaConcurrency in Practice



  But isn't that receiver of the array is another thread? So if
encodeIntoResponse can mess up array, there can be concurency issues?


----------------------------------------------------------------------------
    From: dcholmes at optusnet.com.au
    To: unmesh_joshi at hotmail.com; concurrency-interest at cs.oswego.edu
    Subject: RE: [concurrency-interest] Cloning in CachingFactorizer in
JavaConcurrency in Practice
    Date: Wed, 23 Jan 2008 14:40:41 +1000


    The cloning isn't for concurrency reasons but just the usual defensive
copying so that the receiver of the array can't mess with the original
contents.

    Effective Java item 24.

    Cheers,
    David Holmes
      -----Original Message-----
      From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Unmesh joshi
      Sent: Wednesday, 23 January 2008 2:09 PM
      To: concurrency-interest at cs.oswego.edu
      Subject: [concurrency-interest] Cloning in CachingFactorizer in
JavaConcurrency in Practice


      Hi,

      I just started reading Java Concurrency in practice. In the following
CachingFactorizer example


      BigInteger i = extractFromRequest(req);

      BigInteger[] factors = null;

      synchronized (this) {

      ++hits;

      if (i.equals(lastNumber)) {

      ++cacheHits;

      factors = lastFactors.clone();

      }

      }

      if (factors == null) {

      factors = factor(i);

      synchronized (this) {

      lastNumber = i;

      lastFactors = factors.clone();

      }

      }

      encodeIntoResponse(resp, factors);

      }



      factors and lastFactors are cloned in the synchronized blocks, but
there is no explanation at that point why they are cloned. In the Object
Sharing section, stack confinement is discussed, but using a different
example. I think it will help reader if a note is added at that point saying
that cloning here is for stack confinement, because assignments to factors
or lastfactors is indirectly publishing the array to other thread which can
be processing the array in encodeIntoResponse method.



      Thanks,

      Unmesh



--------------------------------------------------------------------------
      Live the life in style with MSN Lifestyle. Check out! Try it now!


----------------------------------------------------------------------------
--
  Post free auto ads on Yello Classifieds now! Try it now!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20080123/09e6c18d/attachment.html 


More information about the Concurrency-interest mailing list