[concurrency-interest] Enforcing ordered execution of critical sections?

Joe Bowbeer joe.bowbeer at gmail.com
Thu Dec 25 22:59:07 EST 2014


Thanks for the pointer to DelayQueue.  The PriorityQueue<Condition>
synchronizer thing I wrote looks similar to a DelayQueue on the inside.
One functions like a sequenced lock, the other functions as a
time-sequenced queue.

I agree that using DelayQueue directly would be a bit of a stretch.  I
think it would be better to implement an InOrderQueue instead, and I think
its implementation would be a little simpler than DelayQueue.

On Thu, Dec 25, 2014 at 6:51 PM, Josh Humphries <jh at squareup.com> wrote:

> In that case, you could use a DelayQueue, which is how scheduled executors
> avoid executing the first arrival if it's scheduled for the future.
>
> You could adapt submitted Runnables as instances of Delayed so that the
> delay is computed as their index minus that of the next to be processed
> (which starts at zero and increments after each task).
>
> Though at that point, it may be no simpler than just a custom execution
> mechanism as already discussed here...
>
>
> ----
> *Josh Humphries*
> Manager, Shared Systems  |  Platform Engineering
> Atlanta, GA  |  678-400-4867
> *Square* (www.squareup.com)
>
> On Wed, Dec 24, 2014 at 11:02 AM, Joe Bowbeer <joe.bowbeer at gmail.com>
> wrote:
>
>> Apparently the critical sections need to execute exactly in their pre
>> assigned orders: 1, 2, 3, etc.
>>
>> An executor with an ordered queue would exec the first arrival first.
>>
>>
>> On Wednesday, December 24, 2014, Doug Lea <dl at cs.oswego.edu> wrote:
>>
>>> On 12/13/2014 11:26 PM, Hanson Char wrote:
>>>
>>>> I am looking for a construct that can be used to efficiently enforce
>>>> ordered execution of multiple critical sections, each calling from a
>>>> different thread. The calling threads may run in parallel and may call
>>>> the execution method out of order.
>>>>
>>>
>>> Looking at this again while contemplating the need for
>>> priority-based semaphores...
>>>
>>> Have you considered creating a separate single-threaded
>>> executor using a PriorityBlockingQueue? You'd need to
>>> define a comparator for ordering, and then construct
>>> via something like
>>>
>>> Executor ex = new ThreadPoolExecutor(1, 1, 0L, TimeUnit.MILLISECONDS,
>>>  new PriorityBlockingQueue<Runnable>(initialCap, taskComparator)));
>>>
>>> You'd then use this executor only for the execCriticalSection
>>> tasks.
>>>
>>> -Doug
>>>
>>>
>>>> /**
>>>>   * Used to enforce ordered execution of critical sections calling from
>>>> multiple
>>>>   * threads, parking and unparking the threads as necessary.
>>>>   */
>>>> public class OrderedExecutor<T> {
>>>>      /**
>>>>       * Executes a critical section at most once with the given order,
>>>> parking
>>>>       * and unparking the current thread as necessary so that all
>>>> critical
>>>>       * sections executed by different threads using this executor take
>>>> place in
>>>>       * the order from 1 to n consecutively.
>>>>       */
>>>>      public T execCriticalSectionInOrder(final int order,
>>>>              final Callable<T> criticalSection) throws
>>>> InterruptedException;
>>>> }
>>>>
>>>> Regards,
>>>> Hanson
>>>> _______________________________________________
>>>> Concurrency-interest mailing list
>>>> Concurrency-interest at cs.oswego.edu
>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>>
>>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>
>> _______________________________________________
>> 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/20141225/b87dab32/attachment.html>


More information about the Concurrency-interest mailing list