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

Well, no. Your claim was that the thread may interact with AWT, and still
get the loop variable hoisted. You did not show an example of that
happening.


Alex

On Mon, 19 Jul 2021, 22:41 Gregg Wonderly, <[email protected]> wrote:

> With the logging in there, it’s not happening, because then the compiler
> can’t determine what the end state is, so it doesn’t hoist the read.   But,
> if there are no such things happening, then it’s going to hoist it.  Those
> subtle “conditions” of the hoist make it even more frustrating, because you
> can sprinkle in logging like this and see it work, but then take the stuff
> back out and it stops working…
>
> Gregg Wonderly
>
> On Jul 19, 2021, at 1:25 PM, Alex Otenko <[email protected]>
> wrote:
>
> Does this even get hoisted? setText in the loop is thread safe, and the
> mutation goes through a lock, so no level of inlining should be able to
> allow the elimination of the read that you are concerned about. (And
> certainly no one hoists the read without proving the absence of volatile
> loads in the loop body)
>
> Alex
>
> On Mon, 19 Jul 2021, 15:17 Gregg Wonderly, <[email protected]> wrote:
>
>> Here’s what I’ve repeatedly shown in these conversations in the past.
>> There is no explicit indication of Thread usage.  This is just a plain and
>> simple swing application that would be the kind of framework that the first
>> Swing application would be written using.  But even some of the things I am
>> doing here are a bit more than what I would expect to see in someones first
>> swing app.
>>
>> Gregg Wonderly
>>
>> import java.awt.*;
>> import java.awt.event.*;
>> import javax.swing.*;
>> import javax.swing.event.*;
>> import java.util.logging.*;
>>
>> public class Example2 extends JFrame {
>>
>>         JTextField tm;
>>         JButton btn;
>>         boolean done;
>>         public static void main( String args[] ) {
>>                 new Example2(args).open();
>>                 System.exit(0);
>>         }
>>
>>         public Example2(String args[] ) {
>>                 JPanel p = new JPanel();
>>                 p.setLayout( new FlowLayout() );
>>                 p.add( btn = new JButton("Press to Exit") );
>>                 p.add( tm = new JTextField(20) );
>>                 this.add(p);
>>                 btn.addActionListener( new ActionListener() {
>>                         public void actionPerformed( ActionEvent ev ) {
>>
>> Logger.getLogger(Example2.class.getName()).info("done...");
>>                                 done = true;
>>                         }
>>                 });
>>                 done = false;
>>         }
>>
>>         public void open() {
>>                 pack();
>>                 setLocationRelativeTo(null);
>>                 setVisible(true);
>>
>> // Does your JVM convert this statement to if( !done ) { while( true ){
>> ...  } }?
>>                 while( !done ) {
>>                         tm.setText(""+new java.util.Date() );
>>                         try {
>>                                 Thread.sleep(500);
>>                         } catch( Exception ex ) {
>>                                 Logger.getLogger(Example2.class.getName())
>>                                         .log( Level.SEVERE,
>> ex.getMessage(), ex );
>>                         }
>>                 }
>>         }
>> }
>>
>> On Jul 19, 2021, at 2:40 AM, Alex Otenko via Concurrency-interest <
>> [email protected]> wrote:
>>
>> I think a piece of code would move this discussion from handwaving to
>> something concrete. If there is some interaction with AWT, the variable you
>> complain about cannot be hoisted. If there is no interaction, then the
>> complaint reduces from "perfectly good code is perfectly broken" to
>> "perfectly broken code is perfectly broken".
>>
>> Without an example everyone is left guessing why anyone would attempt to
>> use a debugger to diagnose a race condition.
>>
>> Alex
>>
>> On Mon, 19 Jul 2021, 03:32 Gregg Wonderly, <[email protected]> wrote:
>>
>>> You are misunderstanding my assertion.  I am only stating that the code
>>> is changed from could work under some circumstances, to unexplainably never
>>> working.  In other words, a debugger would make non volatile code work,
>>> because all of its code running, would cause processor instructions that
>>> would likely make cache line isolation impossible to experience.
>>>
>>> This then becomes documentable side effects of data races.  But
>>> realistically, as Brian stated, any mult-threaded behaviors in desktop apps
>>> are not very obvious, and data races are often not experienced because of
>>> how the app thread and the awt event queue interact.
>>>
>>> Gregg
>>>
>>> Sent from my iPhone
>>>
>>> On Jul 18, 2021, at 6:09 PM, Alex Otenko via Concurrency-interest <
>>> [email protected]> wrote:
>>>
>>> 
>>> 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
>>>
>>> _______________________________________________
>> 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