[Info-vax] yet another sys$qiow question

[Johnny Billquist]

On 2015-08-21 14:07, David Froble wrote:
> 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.

Are you saying that it is a poorly written program if it do not use ASTs???

My example code will wait on the event flag. And it will fail if you 
don't declare the iosb as volatile.

	Johnny