On 10/12/2014 4:15 AM, Martin Buchholz wrote:
On Mon, Dec 8, 2014 at 8:35 PM, David Holmes wrote:
So (as you say) with TSO you don't have a total order of stores if you
read your own writes out of your own CPU's write buffer. However, my
interpretation of "multiple-copy atomic" is that the in
Yes, I read the part of that paper about IRIW.
My thinking that the ordering of stores would be the more contentious
point also appears about the same thing.
In IRIW we have two parts of chain that's reasonable to expect to work:
x=1 <-- sw -- r1=x <-- po -- r2=y
y=1 <-- sw -- r3=y <-- po --
The "no known useful benefit" is based on the paper which states "we are not
aware of any cases where IRIW arises as a natural programming idiom".
I think your example would be written:
Thread 1:
x =1; storestore; y=1;
Thread 2:
r1 = y; r2 =x.
Or more clearly, the most common pattern would be:
Apologies Patrick, that's me who misread you. I assume I had a mix of your
reply, our recent conversation and David's question in my head.
About your actual reply. That's probably a matter of taste, since nowhere else
except for this particular method this thing is not used (in java.nio.file.Files
Yes you are right - forcing global visibility does ensure ordering.
David
-Original Message-
From: Oleksandr Otenko [mailto:oleksandr.ote...@oracle.com]
Sent: Wednesday, 10 December 2014 8:59 AM
To: dhol...@ieee.org; Hans Boehm
Cc: core-libs-dev; concurrency-inter...@cs.oswego.ed
Hi Chris,
> Am 09.12.2014 um 23:58 schrieb Chris Hegarty :
>
>
>> On 9 Dec 2014, at 22:24, Pavel Rappo wrote:
>>
>>
>>> 2) I would extract the buffer size to a constant as in the NIO Files class
>>
>> Patrick, we've discussed it already. Correct me if I wrong, but we came to
>> the
>> conclu
I see it differently. The issue is ordering - the inability of non-TSO
platforms enforce total order of independent stores. The first loads are
also independent and their ordering can neither be enforced, nor
detected. But the following load can detect the lack of total ordering
of stores and l
> On 9 Dec 2014, at 22:24, Pavel Rappo wrote:
>
>
>> 2) I would extract the buffer size to a constant as in the NIO Files class
>
> Patrick, we've discussed it already. Correct me if I wrong, but we came to the
> conclusion that there's not enough evidence to support the need for this
> metho
Hi Pavel,
>> 2) I would extract the buffer size to a constant as in the NIO Files class
>
I may expressed myself not clear in my comment. I just wanted to point out, if
the buffer size may should be extracted to a private static constant. The
java.nio.file.Files class was meant to be an exampl
> In the transferTo then transferred needs to be a long.
> „transferred“ should be a long instead of int
Good catch, guys!
> ...the method names are inconsistent (the methods in lower case with embedded
> underscores)
Fixed. Updated webrev: http://cr.openjdk.java.net/~prappo/8066867/webrev.01
> 2) I would extract the buffer size to a constant as in the NIO Files class
Patrick, we've discussed it already. Correct me if I wrong, but we came to the
conclusion that there's not enough evidence to support the need for this method.
-Pavel
In that case I must say I can't see why you mentioned "no known useful
benefit". The known useful benefit from ordering reads can be seen here:
store in one order:
Thread 1:
x=1
y=1
load in reverse order:
Thread 2:
r1=y;
r2=x;
This is a common pattern, so ordering loads is already useful. Here
In this case the issue is not ordering per-se (which is what dependencies
help with) but global visibility. After performing the first read each
thread must ensure that its second read will return what the other thread
saw for the first read - hence a full dmb/sync between the reads; or
generalizin
Yes, I do understand the reader needs barriers, too. I guess I was
wondering more why the reader would need something stronger than what
dependencies etc could enforce. I guess I'll read what Martin forwarded
first.
Alex
On 09/12/2014 21:37, David Holmes wrote:
See my earlier response to Mar
See my earlier response to Martin. The reader has to force a consistent view
of memory - the writer can't as the write escapes before it can issue the
barrier.
David
-Original Message-
From: concurrency-interest-boun...@cs.oswego.edu
[mailto:concurrency-interest-boun...@cs.oswego.edu]O
The "thorn" is the need for the barriers in the readers not the writers. (or
perhaps as well as the writers in some cases - that is part of the problem.)
David
-Original Message-
From: concurrency-interest-boun...@cs.oswego.edu
[mailto:concurrency-interest-boun...@cs.oswego.edu]On Beha
Is the thorn the many allowed outcomes, or the single disallowed
outcome? (eg order consistency is too strict for stores with no
synchronizes-with between them?)
Alex
On 26/11/2014 02:10, David Holmes wrote:
Hi Hans,
Given IRIW is a thorn in everyone's side and has no known useful
benefit,
On Tue, Dec 9, 2014 at 12:04 PM, Oleksandr Otenko
wrote:
> On 26/11/2014 02:04, Hans Boehm wrote:
>>
>> To be concrete here, on Power, loads can normally be ordered by an address
>> dependency or light-weight fence (lwsync). However, neither is enough to
>> prevent the questionable outcome for IR
On 26/11/2014 02:04, Hans Boehm wrote:
To be concrete here, on Power, loads can normally be ordered by an
address dependency or light-weight fence (lwsync). However, neither
is enough to prevent the questionable outcome for IRIW, since it
doesn't ensure that the stores in T1 and T2 will be mad
Hi Martin,
Looks good. I also think the code is easier to read now.
Thanks for switching back to a version with racy but correct initialization. As
Peter wrote, there are many cases where we don’t guarantee == on Type
instances. I can see why that would be desirable, but that is a separate
dis
On Mon, Dec 8, 2014 at 8:35 PM, David Holmes wrote:
>> So (as you say) with TSO you don't have a total order of stores if you
>> read your own writes out of your own CPU's write buffer. However, my
>> interpretation of "multiple-copy atomic" is that the initial
>> publishing thread can choose to
On Mon, Dec 8, 2014 at 8:51 PM, David Holmes wrote:
> Then please point me to the common industry definition of it because I
> couldn't find anything definitive. And as you state yourself above one
> definition of it - the corresponding C11 fence - does not in fact have the
> same semantics!
I c
Oops sorry - classic mistake of forgetting to hg qrefresh before publishing.
On Tue, Dec 9, 2014 at 3:23 AM, Paul Sandoz wrote:
> On Dec 8, 2014, at 11:47 PM, Martin Buchholz wrote:
>> Webrev updated.
>
> Not quite sure how the webrev was updated:
>
>
> http://cr.openjdk.java.net/~martin/webr
On 9 Dec 2014, at 16:17, David M. Lloyd wrote:
> On 12/09/2014 09:47 AM, Pavel Rappo wrote:
>> Hi everyone,
>>
>> Could you please review my change for JDK-8066867?
>>
>> http://cr.openjdk.java.net/~prappo/8066867/webrev.00/
>
> In the NIO version of this method, it accepts a 'long' parameter
Hi Pavel,
1) „transferred“ should be a long instead of int
2) I would extract the buffer size to a constant as in the NIO Files class
-Patrick
> Hi everyone,
>
> Could you please review my change for JDK-8066867?
>
> http://cr.openjdk.java.net/~prappo/8066867/webrev.00/
>
> -
On 12/09/2014 09:47 AM, Pavel Rappo wrote:
Hi everyone,
Could you please review my change for JDK-8066867?
http://cr.openjdk.java.net/~prappo/8066867/webrev.00/
In the NIO version of this method, it accepts a 'long' parameter which
indicates how many bytes should be transferred (similar to s
2014/12/9 12:51 -0800, konstantin.she...@oracle.com:
> Please review the test enhancement
> https://bugs.openjdk.java.net/browse/JDK-8066798
The synopsis of this issue begins with "TEST_RFR".
What does that even mean? Why do we need it?
I'm concerned that the proliferation of "TEST*" prefixes
On 09/12/2014 15:47, Pavel Rappo wrote:
Hi everyone,
Could you please review my change for JDK-8066867?
http://cr.openjdk.java.net/~prappo/8066867/webrev.00/
In the transferTo then transferred needs to be a long. I think I would
re-work the loop to make it a bit more readable but that is a so
Hi everyone,
Could you please review my change for JDK-8066867?
http://cr.openjdk.java.net/~prappo/8066867/webrev.00/
The task originated from discussion:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029650
Hi Doug,
On 12/06/2014 05:14 PM, Doug Lea wrote:
On 12/04/2014 07:22 PM, Doug Lea wrote:
Because Random, SplittableRandom, and ThreadLocalRandom all use the
same basic approach, they can/should use the same mechanism.
In other words, to establish a common default-constructor-seed
generator i
on last thing to think about:
does it make sense to move 'if (!run.passed) { ... } else { ... }' code
into TestRun class?
On 12/09/2014 04:03 PM, Konstantin Shefov wrote:
Igor,
I changed the webrev: http://cr.openjdk.java.net/~kshefov/8066798/webrev.02
-Konstantin
On 09.12.2014 15:03, Igor
Igor,
I changed the webrev: http://cr.openjdk.java.net/~kshefov/8066798/webrev.02
-Konstantin
On 09.12.2014 15:03, Igor Ignatyev wrote:
Konstantin,
well, now I don't see any points to have a lambda. you can simple make
it a method in TestRunInfo and rename TestRunInfo into TestRun.
174 t
John, Paul, thanks for the reviews!
Looks ok.
Curiously, is there a reason why you chose to use MH.invokeWithArguments rather
than MH.invoke/invokeExact?
No particular reason. Just didn't want to want to spend time tuning call
site for signature polymorphic method.
Best regards,
Vladimir Iv
On Dec 9, 2014, at 12:47 AM, Vladimir Ivanov
wrote:
> http://cr.openjdk.java.net/~vlivanov/8066746/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8066746
>
Looks ok.
Curiously, is there a reason why you chose to use MH.invokeWithArguments rather
than MH.invoke/invokeExact?
Paul.
>
Konstantin,
well, now I don't see any points to have a lambda. you can simple make
it a method in TestRunInfo and rename TestRunInfo into TestRun.
174 t.printStackTrace();
175 System.err.println("FAILED");
you don't print exception me
On Dec 8, 2014, at 11:47 PM, Martin Buchholz wrote:
> Webrev updated.
Not quite sure how the webrev was updated:
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/
But the patch file
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-s
Hi Igor
Thanks for reviewing.
I have made some changes, added a separate class to store the variables.
"doneIterations" is not local for lambda, it is incremented after each
lambda execution.
Also I changed to catch Exception.
http://cr.openjdk.java.net/~kshefov/8066798/webrev.01
-Konstantin
Hi Konstantin,
0. I don't like static variables which you introduced. were I you, I'd
create a class which encapsulates them.
+ it looks like
- doneIterations is a local for the lambda
- totalIterations is almost affectively final
- testCounter/failCounter are just informative variable and c
Hello,
Please review the test enhancement
https://bugs.openjdk.java.net/browse/JDK-8066798
Webrev is http://cr.openjdk.java.net/~kshefov/8066798/webrev.00
Test has been modified to use
lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java class to define
its number of iterations depending o
39 matches
Mail list logo
