Re: criteria to decide whether method must be synchronized

Discussion in 'Java' started by Justin Fowler, Aug 20, 2003.

  1. You should basically use. If the current thread changes the a shared data
    member, then you method should be synchronised.

    Regards

    Justin Fowler
    Software Engineer


    "Harald Kirsch" <> wrote in message
    news:...
    > Is there a place on the web or a book which
    > contains a list of criteria to apply in order to
    > decide whether a method should be synchronized or
    > not?
    >
    > For example:
    > 1) If the method changes an instance variable which
    > has some non-trivial relation to another instance
    > variable (e.g. first<=last, size describing
    > used number of elements in an array), the method should
    > be synchronized.
    >
    > 2) If the method reallocates and copies an internal array,
    > it should be synchronized (not sure about this).
    >
    > Harald.
    Justin Fowler, Aug 20, 2003
    #1
    1. Advertising

  2. Justin Fowler

    Adam Maass Guest

    "Justin Fowler" <> wrote:
    > You should basically use. If the current thread changes the a shared data
    > member, then you method should be synchronised.
    >


    If the method writes /or/ reads the state of a shared data member, then the
    method should be synchronized.

    -- Adam Maass
    Adam Maass, Aug 20, 2003
    #2
    1. Advertising

  3. "Adam Maass" <> wrote in message news:<>...
    > "Justin Fowler" <> wrote:
    > > You should basically use. If the current thread changes the a shared data
    > > member, then you method should be synchronised.
    > >

    >
    > If the method writes /or/ reads the state of a shared data member, then the
    > method should be synchronized.


    Why also synchronize the readers? If the writers are appropriately
    synchronized, are the readers not protected against garbled internal state?

    Aah, wait. If a reader was entered already in one thread and
    has assembled half the information it wants to return, a writer
    in another thread may get its cpu share, changes
    everything and makes the reader return garbage.

    If the rule is so easy, are there any tools which check this. Should the
    compiler not be able to warn about it?

    Harald.
    Harald Kirsch, Aug 21, 2003
    #3
  4. Harald Kirsch <> scribbled the following:
    > "Adam Maass" <> wrote in message news:<>...
    >> "Justin Fowler" <> wrote:
    >> > You should basically use. If the current thread changes the a shared data
    >> > member, then you method should be synchronised.

    >>
    >> If the method writes /or/ reads the state of a shared data member, then the
    >> method should be synchronized.


    > Why also synchronize the readers? If the writers are appropriately
    > synchronized, are the readers not protected against garbled internal state?


    > Aah, wait. If a reader was entered already in one thread and
    > has assembled half the information it wants to return, a writer
    > in another thread may get its cpu share, changes
    > everything and makes the reader return garbage.


    Yes. That's called a "dirty read": ending up with a read value that's
    no longer in synch with the current one.

    > If the rule is so easy, are there any tools which check this. Should the
    > compiler not be able to warn about it?


    That would require the compiler to know the *intention* of the code.
    How is it to know you did not *intend* for dirty reads to occur?

    --
    /-- Joona Palaste () ---------------------------\
    | Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
    | http://www.helsinki.fi/~palaste W++ B OP+ |
    \----------------------------------------- Finland rules! ------------/
    "You can pick your friends, you can pick your nose, but you can't pick your
    relatives."
    - MAD Magazine
    Joona I Palaste, Aug 21, 2003
    #4
  5. Josef Garvi <> scribbled the following:
    > Joona I Palaste wrote:
    >> That would require the compiler to know the *intention* of the code.
    >> How is it to know you did not *intend* for dirty reads to occur?


    > In what situation(s) could that be desirable?


    I don't know, but which authority am I to decide the desirability of
    any code ever? Which authority is anyone? As long as no one can come up
    with a proof that such-and-such code is *always* bad, there's no point
    making Java forbid it at compile time.

    --
    /-- Joona Palaste () ---------------------------\
    | Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
    | http://www.helsinki.fi/~palaste W++ B OP+ |
    \----------------------------------------- Finland rules! ------------/
    "The truth is out there, man! Way out there!"
    - Professor Ashfield
    Joona I Palaste, Aug 22, 2003
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jerry
    Replies:
    4
    Views:
    131,748
    tonni
    Aug 11, 2010
  2. Pep
    Replies:
    6
    Views:
    29,235
  3. dmcreyno
    Replies:
    9
    Views:
    9,545
    Mark Space
    Jun 27, 2006
  4. QQ
    Replies:
    10
    Views:
    461
    CBFalconer
    Jun 19, 2006
  5. ankur
    Replies:
    4
    Views:
    1,408
    Eric Sosman
    Nov 28, 2008
Loading...

Share This Page