Is ThreadPoolExecutor.execute() thread safe?

Discussion in 'Java' started by Philipp, Oct 27, 2008.

  1. Philipp

    Philipp Guest

    Hello
    I use a ThreadPoolExecutor and submit tasks using execute(Runnable).
    It is not clear to me from the documentation if this method is thread
    safe. Meaning, can I call it from different threads concurrently
    without problems?

    Further, I'm not using Sun's implementation of this class, but rather
    the JVM 1.3 backport found at http://backport-jsr166.sourceforge.net
    If anybody has a specific answer for this implementation, that would
    be even better.

    Thanks Phil
    Philipp, Oct 27, 2008
    #1
    1. Advertising

  2. Philipp

    Lew Guest

    Philipp <wrote:
    >> Further, I'm not using Sun's implementation of this class, but rather
    >> the JVM 1.3 backport found at http://backport-jsr166.sourceforge.net


    Just curious, why are you using an obsolete Java version?

    One of the most significant changes starting with Java 5 (itself in
    End-of-Life) was the repair of the broken (multi-threaded) memory model of
    earlier versions.

    --
    Lew
    Lew, Oct 28, 2008
    #2
    1. Advertising

  3. Philipp

    Lew Guest

    Philipp wrote:
    >> I use a ThreadPoolExecutor and submit tasks using execute(Runnable).
    >> It is not clear to me from the documentation if this method is thread
    >> safe. Meaning, can I call it from different threads concurrently
    >> without problems?


    Peter Duniho wrote:
    > If you are using a non-standard implementation, I suppose there's a chance  
    > it might not be thread-safe.  But I'd consider that a bug.
    >
    > A similar question was just addressed recently:

    <http://groups.google.com/group/comp.lang.java.programmer/
    browse_thread/thread/b488770c7813276/e3282505343a6316?lnk=st&q=group
    %3Acomp.lang.java.programmer+executor#e3282505343a6316>

    Of course Executors are thread-safe. Duhy. That *is* their design
    purpose after all, just like all of the java.util.concurrent packages.

    The Javadocs point to this:
    > Memory consistency effects:
    > Actions in a thread prior to submitting a Runnable object to an Executor
    > /happen-before/ its execution begins, perhaps in another thread.


    That does not automatically mean that one's code written with them
    will be thread-safe, of course. I suggest Brian Goetz (et al.)'s
    excellent and seminal /Java Concurrency in Practice/ for training on
    these matters.

    Philipp wrote:
    > Further, I'm not using Sun's implementation of this class, but rather
    > the JVM 1.3 backport found at http://backport-jsr166.sourceforge.net


    The memory model in Java 1.3 (and 1.4) didn't have the /happens-
    before/ semantics of Java 5 and later. It is possible that would mess
    you up. Upgrade to the current Java version (6).

    --
    Lew
    Lew, Oct 28, 2008
    #3
  4. Idea for getting thread safety documented. Was: Re: Is ThreadPoolExecutor.execute()thread safe?

    Peter Duniho wrote:
    > On Tue, 28 Oct 2008 10:31:12 -0700, Lew <> wrote:
    >
    >> Of course Executors are thread-safe. Duhy. That *is* their design
    >> purpose after all, just like all of the java.util.concurrent packages.

    >
    > While the assumption seems reasonable on the face of it, the fact is I
    > could find no requirement in the Executor interface that implementors be
    > thread-safe. The docs for the java.util.concurrent package say

    ....

    There is a general problem with vague documentation of thread safety.

    This is a bit strange, because Sun decided to fix that for its Solaris
    documentation several years ago. Each library function man page is
    required to specify its "MT-Level". See, for example,
    http://docs.sun.com/app/docs/doc/816-5168/memcpy-3c?a=view.

    The permitted values and their meanings are specified, see
    http://docs.sun.com/app/docs/doc/816-5175/attributes-5?a=view.

    Here is an idea I am thinking of proposing:

    1. Add to Javadoc a facility for specifying thread safety. There should
    be a limited set of values, but not necessarily the same as the ones for
    Sun's Solaris documentation.

    2. Add an option to Javadoc to treat absence of a thread safety
    specification for any public method or constructor as an error.

    3. Encourage API developers, especially Sun's Java developers, to use
    the option.

    What do people think? Are the Sun Solaris MT-Level values a good
    starting point?

    Patricia
    Patricia Shanahan, Oct 28, 2008
    #4
  5. Peter Duniho wrote:
    > On Tue, 28 Oct 2008 10:31:12 -0700, Lew <> wrote:
    >
    >> Of course Executors are thread-safe. Duhy. That *is* their design
    >> purpose after all, just like all of the java.util.concurrent packages.

    >
    > While the assumption seems reasonable on the face of it, the fact is I
    > could find no requirement in the Executor interface that implementors be
    > thread-safe. The docs for the java.util.concurrent package say
    >
    > Depending on which concrete Executor class is being used,
    > tasks may execute in a newly created thread, an existing
    > task-execution thread, or the thread calling execute(),
    > and may execute sequentially or concurrently.
    >
    > The docs for Executor.execute() say (in part);
    >
    > The command may execute in a new thread, in a pooled thread,
    > or in the calling thread, at the discretion of the Executor
    > implementation.
    >
    > Note that concurrent execution is _not_ mandatory from an Executor, and
    > so thread-safety may not be required for some specific Executor
    > implementation.
    >
    > Now, the most recent question is about a specific implementation,
    > ThreadPoolExecutor. But even there, the documentation does not
    > specifically call the class or methods like execute() out as being
    > thread-safe.
    >
    > Personally, I think it's a reasonable assumption that it would be.
    > After all, the usefulness of the class winds up _much_ reduced if it's
    > not thread-safe. But other thread-safe classes and/or methods in Java
    > are specifically described in the documentation as being so. It's a
    > fair question to wonder whether ThreadPoolExecutor is thread-safe, and
    > frankly even as confident I am that it is, I would hesitate to make a
    > _claim_ that it is without some specific documentation supporting the
    > claim.
    >
    > So far, I haven't found that documentation. Do you know where it is?
    >
    > Pete


    The question is what does he mean by 'thread safe'? If he means the
    call to execute(), then I'm sure that is safe (although I can't find
    anything that says so). If he means the actions occurring in the task
    then no, they must be protected as any other multi-threaded code.

    If he means the call to execute() then putting it in a synchronized
    block would be sufficient. But what would that actually protect? I
    think it would only protect the actions of the execute() method which
    just put the task into a BlockingQueue somewhere. There would be no
    reason to synchronize that as the queue is already synchronized.

    So barring some peculiarities of 1.3 and the back port, I think calling
    execute() is thread safe.

    --

    Knute Johnson
    email s/nospam/knute2008/

    --
    Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
    ------->>>>>>http://www.NewsDemon.com<<<<<<------
    Unlimited Access, Anonymous Accounts, Uncensored Broadband Access
    Knute Johnson, Oct 28, 2008
    #5
  6. Philipp

    Philipp Guest

    Peter Duniho wrote:
    > On Tue, 28 Oct 2008 15:51:43 -0700, Knute Johnson
    > <> wrote:


    > I take the question literally: is the method _execute()_ code safe?


    Thank you Pete for putting it more clearly. Yes in fact, I am
    interested to know if _execute()_ is thread safe, that is, if I can
    submit new jobs to the Executor from different threads without
    worrying about synchonization.

    > ThreadPoolExecutor specifically states it uses a BlockingQueue, so yes...I
    > agree that all queue operations will be thread-safe. But the execute()
    > method does other things than manipulating the queue.


    Precisely. From what I read in this thread, there is no guarantee from
    the docs that it is thread safe, but it can be assumed. I will just
    have to rely on the fact that my implementation complies to that (or
    check it myself). I guess that would be a good exercise :)

    I also encourage a more strict inclusion of thread-safe info into docs
    as proposed by Sabine.

    Thanks to all for answers
    Phil
    Philipp, Oct 29, 2008
    #6
  7. Philipp

    Philipp Guest

    Philipp wrote:
    > I also encourage a more strict inclusion of thread-safe info into docs
    > as proposed by Sabine.


    Sorry, that was Patricia. My bad.
    Cheers Phil
    Philipp, Oct 29, 2008
    #7
  8. Philipp

    Lew Guest

    Philipp wrote:
    > Precisely. From what I read in this thread, there is no guarantee from
    > the docs that it is thread safe, but it can be assumed. I will just
    > have to rely on the fact that my implementation complies to that (or
    > check it myself). I guess that would be a good exercise :)


    If 'execute()' weren't thread-safe, the class wouldn't work. It is
    thread-safe, in Java 5 and above.

    --
    Lew
    Lew, Oct 29, 2008
    #8
  9. In article
    <>,
    Philipp <> wrote:

    > Peter Duniho wrote:
    > > On Tue, 28 Oct 2008 15:51:43 -0700, Knute Johnson
    > > <> wrote:

    >
    > > I take the question literally: is the method _execute()_ code safe?

    >
    > Thank you Pete for putting it more clearly. Yes in fact, I am
    > interested to know if _execute()_ is thread safe, that is, if I can
    > submit new jobs to the Executor from different threads without
    > worrying about synchonization.
    >
    > > ThreadPoolExecutor specifically states it uses a BlockingQueue, so
    > > yes...I agree that all queue operations will be thread-safe. But
    > > the execute() method does other things than manipulating the queue.

    >
    > Precisely. From what I read in this thread, there is no guarantee from
    > the docs that it is thread safe, but it can be assumed. I will just
    > have to rely on the fact that my implementation complies to that (or
    > check it myself). I guess that would be a good exercise :)


    When I'm puzzling over such things, I've found it helpful to review
    the API section entitled "Memory Consistency Properties":

    <http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html>

    In particular, "The results of a write by one thread are guaranteed
    to be visible to a read by another thread only if the write operation
    _happens-before_ the read operation." As Lew pointed out, "Actions in a
    thread prior to the submission of a Runnable to an Executor
    _happen-before_ its execution begins." As Pete suggested, this is not
    proof that your code is correct. You still have to verify that your
    program is correctly synchronized, as defined in the JLS, chapter 17,
    section 4.5:

    <http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.4.5>

    --
    John B. Matthews
    trashgod at gmail dot com
    http://home.roadrunner.com/~jbmatthews/
    John B. Matthews, Oct 29, 2008
    #9
  10. Philipp

    Tom Anderson Guest

    Re: Idea for getting thread safety documented. Was: Re: IsThreadPoolExecutor.execute() thread safe?

    On Tue, 28 Oct 2008, Patricia Shanahan wrote:

    > Peter Duniho wrote:
    >> On Tue, 28 Oct 2008 10:31:12 -0700, Lew <> wrote:
    >>
    >>> Of course Executors are thread-safe. Duhy. That *is* their design
    >>> purpose after all, just like all of the java.util.concurrent packages.

    >>
    >> While the assumption seems reasonable on the face of it, the fact is I
    >> could find no requirement in the Executor interface that implementors be
    >> thread-safe. The docs for the java.util.concurrent package say

    > ...
    >
    > There is a general problem with vague documentation of thread safety.
    >
    > This is a bit strange, because Sun decided to fix that for its Solaris
    > documentation several years ago. Each library function man page is
    > required to specify its "MT-Level". See, for example,
    > http://docs.sun.com/app/docs/doc/816-5168/memcpy-3c?a=view.
    >
    > The permitted values and their meanings are specified, see
    > http://docs.sun.com/app/docs/doc/816-5175/attributes-5?a=view.


    I've also seen MT-hot, which i believe means that a function that is
    MT-safe and can have multiple invocations executing concurrently - that's
    stronger than MT-safe, which could involve a lock which only lets one
    thread run it at once.

    > Here is an idea I am thinking of proposing:
    >
    > 1. Add to Javadoc a facility for specifying thread safety. There should
    > be a limited set of values, but not necessarily the same as the ones for
    > Sun's Solaris documentation.


    How about an annotation rather than a javadoc thing?

    > 2. Add an option to Javadoc to treat absence of a thread safety
    > specification for any public method or constructor as an error.


    With an annotation, you could then get the compiler to complain instead of
    javadoc.

    The trouble with this mechanism is that it adds a burden when you're not
    writing threaded code. I guess the idea is that you'd only use it when you
    were.

    How about being able to annotate a method as being threaded, then
    requiring that all methods called by threaded methods be marked as
    threadsafe? I can see lots of ways that wouldn't work, sadly.

    > 3. Encourage API developers, especially Sun's Java developers, to use
    > the option.
    >
    > What do people think?


    I think it's a very good idea, and long overdue.

    > Are the Sun Solaris MT-Level values a good starting point?


    To a point. We don't need Async-Signal-Safe, Fork-Safe or Cancel-Safety,
    so really, we're looking at Safe, Unsafe and MT-Safe. I'm hazy on the
    difference between Safe and MT-Safe - it seems to just be some wishy-washy
    promises about concurrency. So basically, it comes down to Safe and Unsafe
    - which is absolutely fine, but not something you can really say is
    specifically taken from the Solaris levels!

    I then worry about whether this terminology is rich enough for an OO
    language. If there's a method which isn't safe to call in parallel on a
    single object, but is fine to call in parallel on different objects (so
    a.foo() and b.foo() is fine, but a.foo() and a.foo() is not), is that safe
    or not? Presumably not. But then what do i call a method where it's not
    safe to call it on separate objects at the same time? What if i have a
    method which doesn't do anything unsafe to the object it's called on, but
    does do so to its parameters? What if there are relationships between
    objects, so a.foo() is only safe to call from the thread that is currently
    executing b.bar()?

    What would be great is if there was some solid computer-science foundation
    for making statements about thread safety, so that each level had a really
    well-defined meaning. I don't know enough to know if that's possible.

    tom

    --
    I'm angry, but not Milk and Cheese angry. -- Mike Froggatt
    Tom Anderson, Nov 1, 2008
    #10
    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:
    804
  2. Marc E
    Replies:
    0
    Views:
    662
    Marc E
    Apr 29, 2006
  3. Replies:
    11
    Views:
    21,105
  4. Gabriel Rossetti
    Replies:
    0
    Views:
    1,287
    Gabriel Rossetti
    Aug 29, 2008
  5. John Nagle
    Replies:
    5
    Views:
    443
    John Nagle
    Mar 12, 2012
Loading...

Share This Page