misc catchup

[David Holmes]

Hi Doug,

I didn't know this was being folded back into FJP. We'll have to update 
the JEP.

A couple of comments:

1. The new spin-lock stuff using Unsafe directly isn't sending a very 
good message. We're basically saying ReentrantLock is not performant and 
we have to dive under the covers to get performance. :( That may be the 
truth but it is still not a good message.

2. I don't recall if we definitely established that a thread can always 
interrupt itself, but if not I can't quite convince myself that if 
tryAwaitMainLock throws SecurityException that everything continues to 
work ok - deregisterWorker seems problematic as the WorkQueue state has 
already been mutated.

Cheers,
David

On 31/10/2012 2:14 AM, Doug Lea wrote:
>
> As most of you probably probably surmised from
> http://cs.oswego.edu/pipermail/concurrency-interest/2012-October/010182.html
>
> implicit use of the ForkJoinPool.commonPool can/should replace
> the internal ForkJoinUtils in lambda builds. Besides being easier
> to use, and reducing resource use when people are otherwise
> tempted to create their own "default" pools, it exploits knowledge
> of the pool to improve execution times, In particular, fjt.invoke()
> will often be faster than FJP.invoke(fjt); moreso when people use
> some new idioms (including those I've thought of and probably more.)
>
> As usual, I've been using ConcurrentHashMap to explore maximal
> customized bulk op performance (using extremely specialized
> tasks). Using it with commonPool leads to a nicer API and
> better performance.
>
> While I'm at it, a quick digression on all the Encounter Order
> posts: I confess to not understanding "encounter order".
> I understand bulk op semantics on random-access data structures --
> arrays and associative arrays (i.e., ConcurrentHashMaps), which
> is why I focus on them.
> Everything else seems to be a matter of consensus interpretation.
> I understand that everyone wants parallel ops to work on structures
> besides arrays and hash maps, and I am happy to live with Brian's
> attempts to make as much sense of them as possible and have the least
> sucky performance as possible. But both of these concerns will always
> be relative. (And one reason not to complain too much is that the
> Scala folks did approximately the same things and don't seem to
> regret it yet :-)
>
> -Doug
>
>
>
>
>
>