[concurrency-interest] Proposal for a CallerRunsExecutor in j.u.c.Executors

Luke Sandberg lukeisandberg at gmail.com
Sat May 24 18:15:43 EDT 2014


On Sat, May 24, 2014 at 11:03 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 05/23/2014 08:05 PM, Luke Sandberg wrote:
>
>> Guava has an Executor instance called MoreExecutors.sameThreadExecutor
>> <http://docs.guava-libraries.googlecode.com/git/javadoc/
>> com/google/common/util/concurrent/MoreExecutors.html#sameThreadExecutor()
>> >
>>
>>
>> For Guava users it is very popular for passing to APIs like
>> ListenableFuture.addListener and other Executor accepting utilities for
>> when the
>> task will be quick enough that it isn't worth submitting to a thread pool.
>>
>> There was recently a performance bug reported against it:
>> https://code.google.com/p/guava-libraries/issues/detail?id=1734
>>
>> This led to us reconsider the implementation in Guava and then thinking
>> that
>> maybe this should even be a j.u.c.Executors feature.
>>
>
> The class has been sitting there under the name DirectExecutor
> since JDK5 as a code example in the Executors javadoc.
> (See http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/
> concurrent/Executor.html)
> We even discussed putting it (as well as the other code example,
> ThreadPerTaskExecutor) in Executors but for some reason decided
> they weren't important enough. But they are important in that
> standardizing their names and usage will save people work.
> So I can't think of a reason not to do this, even if a decade
> too late for most purposes. Any objections to using these names?


Yeah we noticed the DirectExecutor example too, but consensus appeared to
be against using that name.  Also it was noted that in JCIP Brian Goetz
calls the same thing 'WithinThreadExecutor'.  callerRunsExecutor was
suggested due to the existence of ThreadPoolExecutor.CallerRunsPolicy. (And
there were about 10 thousand other suggestions: immediateExecutor,
currentThreadExecutor, synchronousExecutor,...).

I have no objection to DirectExecutor though I do have a preference for
CallerRunsExecutor.

As for ThreadPerTaskExecutor, that name seems reasonable to me.


>
>
>      MoreExecutors.newCallerRunsExecutorService():
>>        which would be identical to the current sameThreadExecutor() (which
>>     includes shutdown semantics)
>>
>
>
> I gather that this one uses a Lock just to support the
> awaitTermination method? (Otherwise it would need only
> a volatile boolean shutdown bit.) It does seem like a niche usage,
> but maybe someone could make a case for including it.
>

That is correct.  I agree that this is less commonly useful (and it is
often most useful in testing situations).  So just leaving this in Guava
could make sense.  Martin Buchholz suggested just making the
CallerRunsExecutor be a unshutdownable shared ExecutorService instance as a
kind of compromise.


>
> -Doug
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140524/c27f12bd/attachment.html>


More information about the Concurrency-interest mailing list