Re: Are there real use cases with the Java access modes?

I think it is a worthwhile challenge to claim that there is real code that
is free from races, if only all the variables were volatile.

I'd like to see such code.

Somehow I doubt that there is a lot of correct code routinely produced
without consideration of happens-before and the whole memory model shebang.

Alex

On Sun, 18 Jul 2021, 18:54 Gregg Wonderly, <[email protected]> wrote:

> Good software design always includes the notion of least surprise.  In
> which other languages are there examples of Volatile or other optimizations
> that rewrite code to be incorrect based on what the code reads?  There is
> literally no advantage to this rewrite.  Developers can write this code
> exactly if they believe it is beneficial to them.  But having it done by
> default, is a giant surprise and in fact drives people away from Java
> because this looks like a bug, and the compiler still contains zero
> warnings about volatile optimizations that may change logic to not be what
> the code reads.
>
> Literally every single volatile read escape optimization should be issuing
> warnings to the user that their code will not be executed more than once.
> You continue to insist that this is rare code while it is the single most
> common mechanism for controlling UI actions.  Whether it’s a boolean or an
> object reference, this optimization is a huge detriment to new developers
> trying out Java desktop apps.
>
> Gregg Wonderly
>
> Sent from my iPhone
>
> On Jul 18, 2021, at 2:35 AM, Alex Otenko <[email protected]>
> wrote:
>
> 
> The simple truth is that there are more ways to write incorrect code than
> there are ways to write correct code. Complex state changes cannot be
> assumed to work correctly, when done concurrently.
>
> And the things that count for "complex" - anything beyond a single bit
> flip 0->1, and never back 1->0, is complex.
>
> There is no point in forbidding one optimisation for the sake of one type
> of system where that's the only problem.
>
> Alex
>
> On Sun, 18 Jul 2021, 05:13 Gregg Wonderly via Concurrency-interest, <
> [email protected]> wrote:
>
>> Yes this was changed at the sane time the JMM defined  and caused
>> implementation of volatile to happen.
>>
>> While this is legal because of the JMM, it causes broken code to happen
>> without the user really understanding why it could happen and that it will
>> happen.  It’s different in significant ways from cache coherency, and it
>> worked prior to JDK1.5.  I still believe that volatile creates a giant
>> surprise.  This is an optimization behavior that “breaks” code without the
>> user electing to have such an optimization performed!
>>
>> The default variable declaration should be volatile and a different
>> mechanism should be necessary to get non-volatile optimizations to happen.
>> A user should never, ever, be able to write non-working code using default
>> language constructs.
>>
>> Look at the past examples in C-Language and C++ etc.  Things like
>> Register optimizations and many other constructs required the user to break
>> their code, rather than that being the default behavior!
>>
>> Gregg Wonderly
>>
>> Sent from my iPhone
>>
>> On Jul 17, 2021, at 5:05 PM, Shuyang Liu <[email protected]> wrote:
>>
>> Thanks you!
>>
>>  I guess this is before Java 9? So I think “nonVolatileRefExpr” is
>> equivalent to a plain access in this case. The compiler probably identified
>> it as a local access since it is not marked as volatile (then its indeed
>> equivalent to an infinite loop, which makes the transformation valid). Do
>> you know if there’s any applications/bug report with this pattern?
>>
>> Best Regards,
>> Shuyang
>>
>> On Jul 17, 2021, at 1:46 PM, Gregg Wonderly <[email protected]> wrote:
>>
>> One of the standing problems I have is optimizations around non-volatile
>> value references.  Currently, there are visibility optimizations that turn
>>
>> while( nonVolatileRefExpr ) {}
>>
>> Into
>>
>> if( nonVolatileRefExpr ) { while( true ) {} }
>>
>> Which creates infinite loops.  This makes one of the most common types of
>> applications written in Swing to fail to work as the code is written.
>>
>> Gregg Wonderly
>>
>> Sent from my iPhone
>>
>> On Jul 17, 2021, at 4:33 PM, Shuyang Liu via Concurrency-interest <
>> [email protected]> wrote:
>>
>> 
>> Hello,
>>
>> My colleagues and I have been working on a formal model for the Java
>> access modes that is added since Java 9 [1]. Are there any popular use
>> cases of access modes in real world applications/frameworks/libraries? We
>> would like to see how our current formal model works in real examples.
>>
>> Thanks you,
>> Shuyang Liu
>>
>> [1]. Using JDK 9 Memory Order Modes
>> http://gee.cs.oswego.edu/dl/html/j9mm.html
>> _______________________________________________
>> Concurrency-interest mailing list
>> [email protected]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> [email protected]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest