Threads and statics

Discussion in 'Java' started by Dirk Bruere at NeoPax, Apr 7, 2011.

  1. Is there a problem with multiple threads using the same static method of
    a class?

    --
    Dirk

    http://www.neopax.com/technomage/ - My new book - Magick and Technology
     
    Dirk Bruere at NeoPax, Apr 7, 2011
    #1
    1. Advertising

  2. On 7 Apr., 14:41, Patricia Shanahan <> wrote:
    > On 4/7/2011 5:34 AM, Dirk Bruere at NeoPax wrote:
    >
    > > Is there a problem with multiple threads using the same static method of
    > > a class?

    >
    > The local variables for a method go on the calling thread's stack,
    > regardless of whether the method is static or not.
    >
    > Static data presents the same issues when accessed from a static method
    > as when accessed from non-static methods.


    I would word it differently: shared mutable state presents concurrency
    issues if not properly synchronized. Whether the data is stored in a
    static variable or a member variable (or even a database outside the
    JVM) does not really matter for the concurrency implications.

    Kind regards

    robert
     
    Robert Klemme, Apr 7, 2011
    #2
    1. Advertising

  3. Dirk Bruere at NeoPax

    Lew Guest

    On Apr 7, 10:38 am, Robert Klemme <> wrote:
    > On 7 Apr., 14:41, Patricia Shanahan <> wrote:
    >
    > > On 4/7/2011 5:34 AM, Dirk Bruere at NeoPax wrote:

    >
    > > > Is there a problem with multiple threads using the same static methodof
    > > > a class?

    >
    > > The local variables for a method go on the calling thread's stack,
    > > regardless of whether the method is static or not.

    >
    > > Static data presents the same issues when accessed from a static method
    > > as when accessed from non-static methods.

    >
    > I would word it differently: shared mutable state presents concurrency
    > issues if not properly synchronized.  Whether the data is stored in a
    > static variable or a member variable (or even a database outside the
    > JVM) does not really matter for the concurrency implications.
    >


    You'd be wording a different "it". The problems go beyond concurrency
    issues. They can present in single-threaded code, too.

    For example, the dreaded 'java.util.ConcurrentModificationException'
    is not limited to multithreaded scenarios.

    --
    Lew
     
    Lew, Apr 7, 2011
    #3
  4. Dirk Bruere at NeoPax

    markspace Guest

    On 4/7/2011 5:34 AM, Dirk Bruere at NeoPax wrote:
    > Is there a problem with multiple threads using the same static method of
    > a class?
    >



    Yes. There's a problem with anything involving multiple threads, if you
    do it wrong.

    We'll need an SSCCE to help you more. Meantime, Google for
    Java+concurrency.

    <http://download.oracle.com/javase/tutorial/essential/concurrency/>
     
    markspace, Apr 7, 2011
    #4
  5. On 11-04-07 12:20 PM, Lew wrote:
    > On Apr 7, 10:38 am, Robert Klemme <> wrote:
    >> On 7 Apr., 14:41, Patricia Shanahan <> wrote:
    >>
    >>> On 4/7/2011 5:34 AM, Dirk Bruere at NeoPax wrote:

    >>
    >>>> Is there a problem with multiple threads using the same static method of
    >>>> a class?

    >>
    >>> The local variables for a method go on the calling thread's stack,
    >>> regardless of whether the method is static or not.

    >>
    >>> Static data presents the same issues when accessed from a static method
    >>> as when accessed from non-static methods.

    >>
    >> I would word it differently: shared mutable state presents concurrency
    >> issues if not properly synchronized. Whether the data is stored in a
    >> static variable or a member variable (or even a database outside the
    >> JVM) does not really matter for the concurrency implications.
    >>

    >
    > You'd be wording a different "it". The problems go beyond concurrency
    > issues. They can present in single-threaded code, too.
    >
    > For example, the dreaded 'java.util.ConcurrentModificationException'
    > is not limited to multithreaded scenarios.
    > --
    > Lew


    It's not, and in fact most occurrences of
    ConcurrentModificationException I've seen are not in multi-threaded
    situations, they are in single-threaded scenarios.

    I sort of wish they'd come up with a different name than
    ConcurrentModificationException; the exception usually has to do with
    iterators in the presence of modification of the iterated thing, and the
    name of the exception doesn't reflect that. If I don't have iterators
    involved I can concurrently modify to my heart's content (although I
    probably don't want to).

    AHS
    --
    That's not the recollection that I recall...All this information is
    certainly in the hands of the auditor and we certainly await his report
    to indicate what he deems has occurred.
    -- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
    the shit
     
    Arved Sandstrom, Apr 7, 2011
    #5
  6. Dirk Bruere at NeoPax

    Eric Sosman Guest

    On 4/7/2011 8:34 AM, Dirk Bruere at NeoPax wrote:
    > Is there a problem with multiple threads using the same static method of
    > a class?


    No. There's also no problem with multiple threads using the
    same instance method of a class, or even of a particular instance.

    What matters is whether the methods use the same data. Static
    or instance, it's the data-sharing that requires synchronization or
    other special handling -- conversely, it's the non-sharing that
    requires no care at all.

    Advice that I found illuminating when first learning about
    threading: Don't think about the code, think instead about the data
    the code manipulates (more generally, about the "state" the code
    manipulates). Make sure the data is always seen in a consistent
    state, except perhaps by the *one* thread that's in the act of
    changing it; then you'll have a correct program. (It might not be
    the fastest possible program -- that's where the hard parts come
    in -- but at least it won't have race conditions.)

    --
    Eric Sosman
    d
     
    Eric Sosman, Apr 8, 2011
    #6
  7. Dirk Bruere at NeoPax

    Stefan Ram Guest

    Eric Sosman <> writes:
    >manipulates). Make sure the data is always seen in a consistent
    >state, except perhaps by the *one* thread that's in the act of
    >changing it; then you'll have a correct program.


    It still could have potential deadlocks.

    IIRC, deadlocks can happen when two threads each need two
    resources and already have obtained access to one of them.
    Each thread now waits for the other one to release the
    other resource.

    I have little knowledge about multithreading, but from this
    it seems that one can avoid deadlocks as long as one can
    avoid situations where more than one resource needs to be
    obtained for exclusive access at the same time.

    From what I heard, for any realistic project, it is
    impossible to be sure that one got this right. For example,
    a program was written by experts in multithreading and then
    showed a deadlock the first time after several years of use.
     
    Stefan Ram, Apr 9, 2011
    #7
  8. On 09/04/2011 18:08, Stefan Ram allegedly wrote:
    > I have little knowledge about multithreading, but from this
    > it seems that one can avoid deadlocks as long as one can
    > avoid situations where more than one resource needs to be
    > obtained for exclusive access at the same time.


    That's a tautology. But there *are* cases where you need exclusive
    access to more than one resource at the same time. The very fact that
    multi-threaded programs exists proves one can avoid deadlocks in such
    cases -- no need to look any further.

    > For example,
    > a program was written by experts in multithreading and then
    > showed a deadlock the first time after several years of use.


    Beware of the "experts"!

    --
    DF.
    An escaped convict once said to me:
    "Alcatraz is the place to be"
     
    Daniele Futtorovic, Apr 9, 2011
    #8
  9. Dirk Bruere at NeoPax

    Stefan Ram Guest

    Daniele Futtorovic <> writes:
    >That's a tautology. But there *are* cases where you need exclusive
    >access to more than one resource at the same time.


    Inventing freely without knowledge, I would first try to pack
    such resources into a single »meta resource«, which then can
    be obtained or released by a single atomic action, again.

    >The very fact that multi-threaded programs exists proves one
    >can avoid deadlocks in such cases -- no need to look any
    >further.


    Then, the existence of erroneous programs would prove what?

    For the meaning of the verb »prove« in software engineering,
    see for example this report:

    http://machineslikeus.com/news/building-safety-nets-critical-systems
     
    Stefan Ram, Apr 9, 2011
    #9
  10. Dirk Bruere at NeoPax

    Lew Guest

    Stefan Ram wrote:
    > Daniele Futtorovic writes:
    >> That's a tautology. But there *are* cases where you need exclusive
    >> access to more than one resource at the same time.


    > Inventing freely without knowledge, I would first try to pack
    > such resources into a single »meta resource«, which then can
    > be obtained or released by a single atomic action, again.


    >> The very fact that multi-threaded programs exists proves one
    >> can avoid deadlocks in such cases -- no need to look any
    >> further.


    > Then, the existence of erroneous programs would prove what?
    >
    > For the meaning of the verb »prove« in software engineering,
    > see for example this report:
    >
    > http://machineslikeus.com/news/building-safety-nets-critical-systems
    >
    > .


    The book /Java Concurrency in Practice/ (informally, JCIP) by Goetz, et al.,
    shed light on these issues for me.

    If there is a well-defined order of acquisition for multiple locks, you can
    avoid deadlock. Trouble arises when acquirers act in different sequence,
    e.g., one grabs A then B, whilst another grabs B then A.

    One lock for multiple resources is another pattern in the book. It goes into
    detail on how to reason about such scenarios.

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, Apr 9, 2011
    #10
  11. Dirk Bruere at NeoPax

    Eric Sosman Guest

    On 4/9/2011 12:08 PM, Stefan Ram wrote:
    > Eric Sosman<> writes:
    >> manipulates). Make sure the data is always seen in a consistent
    >> state, except perhaps by the *one* thread that's in the act of
    >> changing it; then you'll have a correct program.

    >
    > It still could have potential deadlocks. [...]


    I also wrote, in the part you snipped

    >> (It might not be
    >> the fastest possible program -- that's where the hard parts come
    >> in -- but at least it won't have race conditions.)


    Deadlock is merely a performance problem. A really, Really,
    REALLY bad performance problem. ;)

    --
    Eric Sosman
    d
     
    Eric Sosman, Apr 9, 2011
    #11
  12. "Eric Sosman" <> wrote in message
    news:inqa79$3j7$...
    > On 4/9/2011 12:08 PM, Stefan Ram wrote:
    >> Eric Sosman<> writes:
    >>> manipulates). Make sure the data is always seen in a consistent
    >>> state, except perhaps by the *one* thread that's in the act of
    >>> changing it; then you'll have a correct program.

    >>
    >> It still could have potential deadlocks. [...]

    >
    > I also wrote, in the part you snipped
    >
    > >> (It might not be
    > >> the fastest possible program -- that's where the hard parts come
    > >> in -- but at least it won't have race conditions.)

    >
    > Deadlock is merely a performance problem. A really, Really,
    > REALLY bad performance problem. ;)



    There's a reason it's not call slightlyilllock.
     
    Mike Schilling, Apr 11, 2011
    #12
  13. Dirk Bruere at NeoPax

    Tom Anderson Guest

    On Sun, 10 Apr 2011, Mike Schilling wrote:

    > "Eric Sosman" <> wrote in message
    > news:inqa79$3j7$...
    >> On 4/9/2011 12:08 PM, Stefan Ram wrote:
    >>> Eric Sosman<> writes:
    >>>> manipulates). Make sure the data is always seen in a consistent
    >>>> state, except perhaps by the *one* thread that's in the act of
    >>>> changing it; then you'll have a correct program.
    >>>
    >>> It still could have potential deadlocks. [...]

    >>
    >> I also wrote, in the part you snipped
    >>
    >> >> (It might not be
    >> >> the fastest possible program -- that's where the hard parts come
    >> >> in -- but at least it won't have race conditions.)

    >>
    >> Deadlock is merely a performance problem. A really, Really,
    >> REALLY bad performance problem. ;)

    >
    > There's a reason it's not call slightlyilllock.


    It's only a fleshwoundlock!

    tom

    --
    Science of a sufficiently advanced form is indistinguishable from magic
     
    Tom Anderson, Apr 11, 2011
    #13
  14. Dirk Bruere at NeoPax

    Lew Guest

    Tom Anderson wrote:
    > Mike Schilling wrote:
    >> Eric Sosman wrote:
    >>> Deadlock is merely a performance problem. A really, Really,
    >>> REALLY bad performance problem. ;)


    >> There's a reason it's not call slightlyilllock.


    > It's only a fleshwoundlock!


    Caught between a rock and a hard place - it's a flintlock.

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, Apr 11, 2011
    #14
    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. Jason

    Statics and connections

    Jason, Dec 6, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    1,777
    Jason
    Dec 6, 2004
  2. Roedy Green

    statics in inner classes

    Roedy Green, Jul 1, 2005, in forum: Java
    Replies:
    14
    Views:
    750
    Thomas G. Marshall
    Jul 12, 2005
  3. Spacen Jasset

    Intialisation order and statics

    Spacen Jasset, Jan 31, 2005, in forum: C++
    Replies:
    6
    Views:
    412
    Spacen Jasset
    Jan 31, 2005
  4. Stuart MacMartin
    Replies:
    5
    Views:
    574
    Victor Bazarov
    Jul 27, 2005
  5. Replies:
    3
    Views:
    936
    Thomas Matthews
    Sep 9, 2006
Loading...

Share This Page