gmane.comp.java.jsr.166-concurrency

Re: synchronization based on a key

√iktor Ҡlang — 2012-05-24T15:56:22


Wow, I'd never do that.
How about just having a map from String to Semaphore?

Cheers,
√

Re: synchronization based on a key

R.A. Porter — 2012-05-24T15:46:53

How about a simpler approach:

void foo(String key) {
  synchronized(key.intern()) {
    // process this key
  }
}

-r


On Thu, May 24, 2012 at 7:22 AM, bhm <bheem< at >sbcglobal.net> wrote:

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest< at >cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

synchronization based on a key

bhm — 2012-05-24T14:22:37

I have a method that needs to be synchronized based on a key passed as
parameter, that is, for same key multiple threads shouldn't be
running. Following is what I did--


static final ConcurrentMap<String,Boolean> IN_PROGRESS =
   new ConcurrentHashMap<String,Boolean>();

void foo(String key){
    if(null == IN_PROGRESS.putIfAbsent(key, Boolean.TRUE)){
      // no other thread is processing this key
      try{
          // process this key
      } finally {
         // done with processing this key
         IN_PROGRESS.remove(key)
      }
    } else {
      // some other thread is running this key, discard it
    }
}

this works if I need to discard the request to process the key from
thread t1 when another thread, t2, is processing that key.

I need help to do following-
make thread t1 wait while t2 is processing the key and resume t1 when
t2 is finish processing same key.

I'm aware that if there are multiple threads t1,t3,t4.. etc waiting
for t2 to finish anyone of these thread can wake up and start
processing the key irrespective of their order (if there is any) of
asking to process the key.

Thanks for help.

Bheem

Re: Quest for the optimal queue

√iktor Ҡlang — 2012-05-24T12:53:20

Hi Andriy,

On Thu, May 24, 2012 at 2:21 PM, Andriy Plokhotnyuk
<plokhotnyuk< at >gmail.com>wrote:



The task will not be rescheduled while it is still running.

Cheers,
√

Re: Quest for the optimal queue

Andriy Plokhotnyuk — 2012-05-24T12:21:03

Hi All,

Thank you, Michael, for sharing idea how to minimize access to volatile
variables.

Here is my attempt to use one of Dmitriy Vyukov's version of multi producer
/ single consumer node based queue in implementation of Scalaz actor instead
of ConcurrentLinkedQueue:
https://github.com/plokhotnyuk/actors/blob/master/src/main/scala/com/github/plokhotnyuk/actors/Actor2.scala

Your hints allowed to improve throughput in ~3x times and decrease latency
on ~20% comparing to Scalaz actor that uses CLQ, here are simple benchmarks
and their results:
https://github.com/plokhotnyuk/actors/blob/master/src/test/scala/com/github/plokhotnyuk/actors/ScalazActor2Test.scala
https://github.com/plokhotnyuk/actors/blob/master/out1.txt#L252

Also I found that the same approach cannot be easy applied for custom
implementations of Akka mailboxes:
https://github.com/plokhotnyuk/actors/blob/master/src/main/scala/com/github/plokhotnyuk/actors/UnboundedMailbox2.scala
https://github.com/plokhotnyuk/actors/blob/master/out1.txt#L48

EDIT: This and other ideas like reusing envelope as node for queue list, or
hacking of fork/join pool to automatically discard actor resheduling
requests while task still running (it will allow avoid of tracking of
running state when adding message to the queue) - can improve not only
throughput but greatly decrease latency too.

Best regards,
Andriy


Michael Barker-4 wrote:

Re: ForkJoinPool does not achieve expectedparallelism

Romain Colle — 2012-05-23T09:25:38

Thanks for the explanation and the quick fix!
Romain

On Wed, May 23, 2012 at 1:17 AM, Doug Lea <dl< at >cs.oswego.edu> wrote:

Re: ForkJoinPool does not achieve expected parallelism

Doug Lea — 2012-05-22T23:17:50

Thanks for the nicely conceived test case!
The problem was lack of a secondary signalling check
(present in previous versions) that isn't now needed
for submissions queues, but sometimes is otherwise.
This is now in updated CVS and jar files.


It allows some parallelization of signalling, by
letting other threads help with wakeups when
they find work.

-Doug

ForkJoinPool does not achieve expectedparallelism

Romain Colle — 2012-05-22T16:20:47

Hi Doug and all,

Using the latest version of the ForkJoinPool available on the jsr166y
website, we ran into an issue/regression with our existing code base.

In our code, we have a single task that scans a fairly large fact table
while applying some filtering conditions. Any row that passes this
condition must then be processed.
The pattern that we use is that the scanning task saves (in an array) the
rows that passed the condition and forks a processing task as soon as we
have enough rows to process (say 1024).
We expect that these processing tasks will be picked up (i.e. stolen) by
the other threads in the pool and executed while we continue scanning and
filtering.
Unrelated to the current issue, we have a completion phase at the end of
the scanning that ensures all the forked tasks have been executed.

To sum it up, we have a single task that scans some data and forks lots of
processing task.
Previously (with the version from a few months back without the worker
queues), this was working perfectly and all the worker threads were kept
busy and executed the processing tasks.
Now, we see that only a few threads are being kept busy with the processing
tasks (in addition to the scanning task). Dozens of threads are idle while
work is piling up.

If have put together a simple test that exhibits this issue:
http://pastebin.com/qz9uifJW

Looking at the ForkJoinPool code, it looks like the issue could be in
ForkJoinPool.WorkQueue.push().
More specifically, we have the following:
                if ((n = (top = s + 1) - base) <= 2) {
                    if ((p = pool) != null)
                        p.signalWork();
                }

If tasks are being forked quickly enough, we will only signal work twice
while the local queue is getting fairly large, and no extra help is being
made available.
I naively modified this code to the following and got back to the initial
behavior (full threads usage):
                if ((n = (top = s + 1) - base) <= pool.parallelism) {
                    if ((p = pool) != null)
                        p.signalWork();
                }

I'm not quite sure why the initial "2" was put there. Was it to avoid
flooding the threads with signals if everybody is already at work? In that
case we could do the signaling only if the AC count is < 0.
I'm sure there is a more elegant solution available, so any advice on
whether this is indeed a core issue or if there is an issue with our pool
usage would be appreciated!

Thanks,

Re: CallerRunsOrRejects for JDK8?

√iktor Ҡlang — 2012-05-21T17:43:12

On Mon, May 21, 2012 at 7:19 PM, Aleksey Shipilev <
aleksey.shipilev< at >gmail.com> wrote:


Problem is all the baggage of ExecutorService. :/

Cheers,
√

Re: CallerRunsOrRejects for JDK8?

Aleksey Shipilev — 2012-05-21T17:19:09

I had always had a feeling this is the difference between
Executor.execute() and ExecutorService.submit(). submit() should not
allow to do caller-runs unless explicitly told so by rejection policy.
I would anticipate lots of people are betting on that.

-Aleksey.

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest< at >cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: a volatile bug?

Kirk Pepperdine — 2012-05-21T08:19:16

Didn't mean to imply this was going to be easy nor error prone. I fully appreciate the difficulties. But we are dealing with a class of bugs that are statistical in nature.. those stats change based on a uncontrollable number of environmental conditions which implies the problem is intractable. That said, we still must test and if the problem has moved from one of a binary (worked, didn't work) to a statistical one, it seems that the testing must move in that direction also... agreed it cannot be perfect but that's no reason for not starting.

For example, I had a biased locking bench that failed occasionally. By making numerous runs I was able to detect cases where the biased locking optimization wasn't applied. All I could sort out is there was some sort of race condition that was affected by were the JVM was loaded into memory.. pure speculation but that was one variable that differed between runs. If I could speculate more, my guess is that there was an underlying time sensitive optimization that some times won and when it did it precluded biased locking from begin applied. Most of this analysis came from a statistical treatment of the benchmarking results.

Another example though not a concurrency one. I have a bench that will readjust Java heap based on -XX:NewRatio setting. If the JVM is loaded in low RAM the JVM will adjust the heap in response to a set load. The JVM will *not* resize when the JVM is loaded in higher RAM. Again, you can't see this with a single test.. in fact, you can't see it with a number of tests unless you load the JVM in different memory segments.

Regards,
Kirk

On 2012-05-21, at 12:48 AM, David Holmes wrote:

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest< at >cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: What's mean TLR?

Rémi Forax — 2012-05-21T07:56:44

ThreadLocalRandom :)


cheers,
Rémi

What's mean TLR?

Min Zhou — 2012-05-21T07:43:42

Hi, all

Here is some lines of comments in ThreadLocalRandom.java

    // Padding to help avoid memory contention among seed updates in
    // different TLRs in the common case that they are located near
    // each other.

What's the above TLR short for ?

Thanks,
Min

Re: a volatile bug?

David Holmes — 2012-05-20T22:48:31

My point was that it is very difficult to write tests that trigger different compilation strategies. As it stands unless people play with the compiler strategies via -XX options then these tests will always behave the same way in that regard, so the coverage is not what you might think.

David



_______________________________________________
Concurrency-interest mailing list
Concurrency-interest< at >cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: a volatile bug?

Kirk Pepperdine — 2012-05-20T17:34:55

I've been rooting around at the hardware level and the best testing idea I've been able to come up with is to treat this stuff as a "trait". Test coverage for this stuff is utterly impossible. I think the best one can do is as you suggested, write the tests, make them statistical in nature and then make it easily available so that the community can run the test them selves. I see this tactic as necessary evil in the future of testing.

Regards,
Kirk

On 2012-05-20, at 7:21 PM, Boehm, Hans wrote:



_______________________________________________
Concurrency-interest mailing list
Concurrency-interest< at >cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: a volatile bug?

Boehm, Hans — 2012-05-20T17:21:52

Good point.  But especially in this area, I still think a widely available test suite would help a lot.  You might miss the problem in your test environment, but if you get everyone who has a threads-related problem and suspects their compiler to run the suite in their environment, I'd guess you would get reasonable coverage.

Hans



_______________________________________________
Concurrency-interest mailing list
Concurrency-interest< at >cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: a volatile bug?

David Holmes — 2012-05-19T23:12:10

It is also very difficult to run tests in a way that tests all possible generated code from the JITs. The OSR form can be different from the "normal" form which can be different from a forced compilation via -Xcomp.

But we definitely need better coverage here.

David



_______________________________________________
Concurrency-interest mailing list
Concurrency-interest< at >cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: a volatile bug?

√iktor Ҡlang — 2012-05-19T13:29:29



Absolutely, I totally agree, I was just so surprised I almost spilled my
espresso.




That's likely the reason it works at all then?

Having run into JVM concurrency bugs it's a bit annoying not to know if
it's my own code, my own test or the JVM which is broken.
Having a cohesive TCK for the JMM would atleast make me blame myself
automatically ;-)

Cheers,
√

Re: a volatile bug?

Doug Lea — 2012-05-19T13:25:04

There is not, to my knowledge, a "hotspot JMM Test suite"
(which is out of my scope).  But there are (three forms of)
j.u.c test suites, that together test most JMM requirements.
But there ought to be a separate one to mop up coverage holes.

-Doug



_______________________________________________
Concurrency-interest mailing list
Concurrency-interest< at >cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: a volatile bug?

√iktor Ҡlang — 2012-05-19T13:16:28

Wait, what, there's no JMM tests? I mean even if these things are
statistical tests at best, they'd at least provide some guard rails.

Cheers,
√

On Sat, May 19, 2012 at 3:09 PM, Doug Lea <dl< at >cs.oswego.edu> wrote:

Re: a volatile bug?

Doug Lea — 2012-05-19T13:09:26

Back during JDK5 development (for JSR 133 and 166), we did create
some such tests (some of which are available in our test/loops CVS)
but they were never collected or systematized into a  hotspot
JMM test suite. I'm not sure whether there was a test (or an
implicit one in any of our jsr166 tests) that hit this particular
case, but my guess is that this C1 (-client) bug arose after
our initial JDK5 testing. (Nearly all "routine" j.u.c tests use
C2 (-server).)  Hopefully this bug will spur more complete regression
testing.

-Doug