Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #3013

Re: Threads and statics

Date 2011-04-09 09:29 -0700
From Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com>
Newsgroups comp.lang.java.programmer
Subject Re: Threads and statics
References <905p9gFpuoU1@mid.individual.net> <inlnjn$6c1$1@dont-email.me> <deadlocks-20110409180331@ram.dialup.fu-berlin.de>
Message-ID <N7CdnWLTgqLgFD3QnZ2dnUVZ_h6dnZ2d@posted.palinacquisition> (permalink)

Show all headers | View raw


On 4/9/11 9:08 AM, Stefan Ram wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid>  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.

That's certainly one approach.  In practice, it can be difficult to 
manage, due to implicit locking that can occur.  For example, a call to 
invokeAndWait() can be blocked by code in the EDT that itself is waiting 
on a lock and not allowing events to be dispatched.  If the code in the 
EDT is waiting on a lock being held by the code calling invokeAndWait(), 
that would deadlock.

>    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.

It's not impossible to get it right.  It just takes some effort and use 
of appropriate design techniques.

One of the most common techniques I'm aware of is to use ordered locks. 
  Locks are assigned a specific priority, and they are permitted to be 
taken only in priority order.  This prevents there ever being any cycles 
in the graph describing the lock dependencies, ensuring against deadlock.

Pete

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Threads and statics Dirk Bruere at NeoPax <dirk.bruere@gmail.com> - 2011-04-07 13:34 +0100
  Re: Threads and statics Patricia Shanahan <pats@acm.org> - 2011-04-07 05:41 -0700
    Re: Threads and statics Robert Klemme <shortcutter@googlemail.com> - 2011-04-07 07:38 -0700
      Re: Threads and statics Lew <lew@lewscanon.com> - 2011-04-07 08:20 -0700
        Re: Threads and statics Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-04-07 18:47 -0300
  Re: Threads and statics markspace <-@.> - 2011-04-07 09:32 -0700
  Re: Threads and statics Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-04-07 21:14 -0400
    Re: Threads and statics Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-04-09 18:15 +0200
      Re: Threads and statics Lew <noone@lewscanon.com> - 2011-04-09 13:06 -0400
    Re: Threads and statics Patricia Shanahan <pats@acm.org> - 2011-04-09 09:29 -0700
    Re: Threads and statics Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-04-09 09:29 -0700
    Re: Threads and statics Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-04-09 14:57 -0400
      Re: Threads and statics "Mike Schilling" <mscottschilling@hotmail.com> - 2011-04-10 23:10 -0700
        Re: Threads and statics Tom Anderson <twic@urchin.earth.li> - 2011-04-11 13:25 +0100
          Re: Threads and statics Lew <noone@lewscanon.com> - 2011-04-11 08:58 -0400

csiph-web