[Info-vax] yet another sys$qiow question

[David Froble]

Johnny Billquist wrote:
> On 2015-08-20 16:42, Craig A. Berry wrote:
>> On 8/20/15 7:48 AM, Simon Clubley wrote:
>>> On 2015-08-20, Craig A. Berry <craigberry at nospam.mac.com> wrote:
>>>> On 8/19/15 8:17 AM, Simon Clubley wrote:
>>>>
>>>>> Although I don't write empty loops for non-volatile variables, gcc can
>>>>> (silently) optimise out other chunks of code that it thinks will never
>>>>> be reached or is otherwise redundant so I would have to consider the
>>>>> possibility that LLVM will do the same as well and that in some
>>>>> circumstances it might do it with empty non-volatile while loops as
>>>>> well.
>>>>
>>>> Since the current Ada on VMS is based on gcc, how can it do concurrency
>>>> if gcc can't? Does it generate lots of volatile statements or just
>>>> disable optimizations?
>>>
>>> I was talking about optimisations performed at compile time based on the
>>> structure of the code.
>>>
>>> Example 1:
>>>
>>>     while(1)
>>>         {
>>>         {whatever}
>>>         }
>>>
>>>     while(1)
>>>         {
>>>         {another bunch of whatever}
>>>         }
>>>
>>> Example 2:
>>>
>>>     {some code}
>>>     while(i == 0)    /* i is _not_ volatile */
>>>         {    /* This is an empty loop */
>>>         }
>>>     {some more code}
>>>
>>> In example 1, I've seen gcc remove the code for the second while loop
>>> completely because it will never be reached. (I sometimes use this
>>> construct during debugging by adding the first while loop in front of
>>> the real while loop to dump some registers and to stop the real while
>>> loop from executing).
>>>
>>> I've never written code in the style of example 2, at least when using
>>> _non-volatile_ variables, but I can see an aggressive optimiser
>>> (especially when it's been told to optimise for size) actually removing
>>> that while loop when only non-volatile variables are involved.
>>>
>>> Example 2 could cause a poorly written program to break if it was
>>> busy-waiting on a non-volatile IOSB block.
>>
>> I think the emphasis here should be on "poorly written program"; I
>> certainly don't see any examples of what you're talking about in
>> SYS$EXAMPLES and I don't see how anyone using the documented methods for
>> making sure the I/O is complete before checking the IOSB would get into
>> this kind of trouble.
> 
> One example that I could think of, that might not be so poorly written 
> code, which could bite you, would be something like:
> 
> SYS$QIO(<arguments>);
> if (iosb == 0) {
>   <do some stuff>
>   <wait for I/O completion>
>   printf("IOSB is now %x\n", iosb);
> }
> 
> which would, with a good optimizing compiler, and iosb not declared as 
> volatile, an output showing that iosb was 0, even though it actually 
> would not be zero.
> 
> Just one example... And pardon my ugly pseudo-C here. :-)
> 
>     Johnny
> 

Thanks for validating Craig's statement.  You don't test the IOSB for 
completion.  If you're doing async I/O, then you wait for the AST or whatever to 
tell you it's complete.