ThreadPoolExecutor backport

Discussion in 'Java' started by Philipp, Jul 31, 2008.

  1. Philipp

    Philipp Guest

    Hello
    I'm using the backport to java 1.4 of Doug Lea's java.util.concurrent
    package. In the doc for ThreadPoolExecutor, there is a snipped of code
    to build a pausable thread pool executor. The snipped is below.
    Q: Why does the boolean flag isPaused need not be volatile?
    As I see it, it will be polled and set by different threads and
    nothing guarantees a memory barrier.
    Q2: Does it make a difference if you are in the 1.4 or java 5 memory
    model?
    Thanks for your comments. Phil

    --- Code from JavaDoc ---

    class PausableThreadPoolExecutor extends ThreadPoolExecutor {
    private boolean isPaused;
    private ReentrantLock pauseLock = new ReentrantLock();
    private Condition unpaused = pauseLock.newCondition();

    public PausableThreadPoolExecutor(...) { super(...);

    protected void beforeExecute(Thread t, Runnable r) {
    super.beforeExecute(t, r);
    pauseLock.lock();
    try {
    while (isPaused) unpaused.await();
    } catch (InterruptedException ie) {
    t.interrupt();
    } finally {
    pauseLock.unlock();
    }
    }

    public void pause() {
    pauseLock.lock();
    try {
    isPaused = true;
    } finally {
    pauseLock.unlock();
    }
    }

    public void resume() {
    pauseLock.lock();
    try {
    isPaused = false;
    unpaused.signalAll();
    } finally {
    pauseLock.unlock();
    }
    }
    }}
    Philipp, Jul 31, 2008
    #1
    1. Advertising

  2. Philipp

    Philipp Guest

    Lew a écrit :
    > Philipp wrote:



    class PausableThreadPoolExecutor extends ThreadPoolExecutor {
    private boolean isPaused;
    private ReentrantLock pauseLock = new ReentrantLock();
    private Condition unpaused = pauseLock.newCondition();

    public PausableThreadPoolExecutor(...) { super(...);

    protected void beforeExecute(Thread t, Runnable r) {
    super.beforeExecute(t, r);
    pauseLock.lock();
    try {
    while (isPaused) unpaused.await();
    } catch (InterruptedException ie) {
    t.interrupt();
    } finally {
    pauseLock.unlock();
    }
    }

    public void pause() {
    pauseLock.lock();
    try {
    isPaused = true;
    } finally {
    pauseLock.unlock();
    }
    }

    public void resume() {
    pauseLock.lock();
    try {
    isPaused = false;
    unpaused.signalAll();
    } finally {
    pauseLock.unlock();
    }
    }
    }}

    > > Q: Why does the boolean flag isPaused need not be volatile?
    > > As I see it, it will be polled and set by different threads and
    > > nothing guarantees a memory barrier.

    >
    > Nothing but the 'pauseLock.lock()', that is.


    Thanks for your non-answer. It made me look harder.
    Actually, the thing that happens is that in beforeExecute(),
    unpaused.await() unlocks the acquired lock pauseLock. This then
    (later) gets locked by resume() where signalAll awakes the waiting
    thread in beforeExecute(). At this time, the waiting thread is awake,
    but cannot execute because it must first reacquire the lock (which is
    still held in resume() ). As soon as resume() releases the lock, it is
    reacquired by beforeExecute(). Now what makes it all work without the
    volatile keyword, is that the unlock() in resume() establishes a
    happens-before relation with respect to a subsequent lock of
    pauseLock. So the value of isPaused is updated as soon as the waiting
    thread starts to run again.

    Phil
    Philipp, Jul 31, 2008
    #2
    1. Advertising

  3. Philipp

    Lew Guest

    Philipp wrote:
    > > > Q: Why does the boolean flag isPaused need not be volatile?
    > > > As I see it, it will be polled and set by different threads and
    > > > nothing guarantees a memory barrier.

    >
    > > Nothing but the 'pauseLock.lock()', that is.

    >
    > Thanks for your non-answer. It made me look harder.


    "non-answer"? It turned to to be exactly the answer, as your
    description clearly shows.

    Happy to help.

    --
    Lew
    Lew, Jul 31, 2008
    #3
  4. On 31.07.2008 15:19, Lew wrote:
    > Philipp wrote:


    Btw, AFAIK the implementation you are using preceded Java 5 so it is not
    a backport.

    >> Q2: Does it make a difference if you are in the 1.4 or java [sic] 5
    >> memory model?

    >
    > Yes, but not to this snippet.


    Are you sure with regard to "volatile"? I faintly remember articles
    about the flaws of the Java memory model before Java 5 and I believe
    volatile handling was one of them. Or am I mixing up something?

    Kind regards

    robert
    Robert Klemme, Jul 31, 2008
    #4
  5. Philipp

    Lew Guest

    On Jul 31, 2:49 pm, Robert Klemme <> wrote:
    > On 31.07.2008 15:19, Lew wrote:
    >
    > > Philipp wrote:

    >
    > Btw, AFAIK the implementation you are using preceded Java 5 so it is not
    > a backport.
    >
    > >> Q2: Does it make a difference if you are in the 1.4 or java [sic] 5
    > >> memory model?

    >
    > > Yes, but not to this snippet.

    >
    > Are you sure with regard to "volatile"?  I faintly remember articles
    > about the flaws of the Java memory model before Java 5 and I believe
    > volatile handling was one of them.  Or am I mixing up something?


    You are correct, but 'volatile' was not used in the snippet, so that
    difference is, as stated, not relevant to the snippet.

    --
    Lew
    Lew, Jul 31, 2008
    #5
  6. On 31.07.2008 20:52, Lew wrote:
    > On Jul 31, 2:49 pm, Robert Klemme <> wrote:
    >> On 31.07.2008 15:19, Lew wrote:
    >>
    >>> Philipp wrote:

    >> Btw, AFAIK the implementation you are using preceded Java 5 so it is not
    >> a backport.
    >>
    >>>> Q2: Does it make a difference if you are in the 1.4 or java [sic] 5
    >>>> memory model?
    >>> Yes, but not to this snippet.

    >> Are you sure with regard to "volatile"? I faintly remember articles
    >> about the flaws of the Java memory model before Java 5 and I believe
    >> volatile handling was one of them. Or am I mixing up something?

    >
    > You are correct, but 'volatile' was not used in the snippet, so that
    > difference is, as stated, not relevant to the snippet.


    Actually I canceled my posting because I discovered my reading error the
    second after hitting "send" - but apparently Usenet was too fast for me. :)

    Thanks for clarifying anyway! Always good to get some of your well
    thought out advice / comments.

    Kind regards

    robert
    Robert Klemme, Jul 31, 2008
    #6
  7. Philipp

    Lew Guest

    Robert Klemme wrote:
    > >> I faintly remember articles
    > >> about the flaws of the Java memory model before Java 5 and I believe
    > >> volatile handling was one of them.  Or am I mixing up something?


    What you are remembering is that 'volatile' prior to Java 5 only
    guaranteed visibility of changes through the volatile variable
    itself. Other changes might not have propagated.

    So given

    class Foo
    {
    volatile int flag;
    int value; // not volatile
    ...
    }

    the old memory model would guarantee visbility of changes to 'flag',
    but not other changes. Code like:

    value += 17;
    flag = 1;

    in one thread guaranteed that another thread would see 'flag' as 1,
    but not that it would see the change in 'value'. In the new memory
    model, the change to 'value' /happens-before/ the change to 'flag', so
    it is visible across threads.

    --
    Lew
    Lew, Jul 31, 2008
    #7
    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. Replies:
    0
    Views:
    818
  2. Daniel Fetchinson

    backport of 'set' to python 2.3?

    Daniel Fetchinson, May 22, 2008, in forum: Python
    Replies:
    1
    Views:
    250
    Daniel Fetchinson
    May 22, 2008
  3. Daniel Fetchinson

    2.5/2.4 multiprocessing backport doc typo

    Daniel Fetchinson, Mar 29, 2009, in forum: Python
    Replies:
    1
    Views:
    337
  4. Trans

    1.9 Backport?

    Trans, Oct 26, 2006, in forum: Ruby
    Replies:
    8
    Views:
    123
    Keith Fahlgren
    Oct 27, 2006
  5. Victor \Zverok\ Shepelev

    Backport from ruby 1.9, including constants

    Victor \Zverok\ Shepelev, Feb 12, 2007, in forum: Ruby
    Replies:
    3
    Views:
    85
    Joel VanderWerf
    Feb 12, 2007
Loading...

Share This Page