Queue async operations on a per-player basis [WIP]

[sgdc3]

No description provided.

[sgdc3]

Depends on #1992

[TuxCoding]

I kind of understand what you are doing here. You are trying to perform asynchronous tasks sequential on per player basis. I guess with the goal to reduce conflicts between them? Do you also thought about locks? This allows more flexibility like read/write differentiation, protecting only thread-unsafe operations meanwhile other parts could execute in concurrently and in parallel.

[TuxCoding]

Potential memory leak

[TuxCoding]

This doesn't seem thread-safe. Considering two calls to the submit method. Then both tasks will be added, but scheduler.apply() will be invoked twice with two new tasks on the Bukkit scheduler resulting to two new threads.

T1 and T2 are the threads:
T1: 1 iteration of the while loop
-- 1 task remaining
T1: evaluate while(!queue.isEmpty()) -> true - enter while loop
T2: 1 iteration of the while loop
-- queue.poll wasn't executed yet by T1 and so queue is still not empty
-- T2 now removes the last task
T1: queue.poll() - NoSuchElementExeception

[sgdc3]

Hmm I see, which pattern should we use instead?

[TuxCoding]

The easiest solution would be to lock on the queue on isEmpty + poll operations.

[sgdc3]

@games647 I think that both read/write operations needs to be sequential, I can't think about any situation where locks might be better. Can you make some examples?