[Info-vax] yet another sys$qiow question
Jan-Erik Soderholm
jan-erik.soderholm at telia.com
Sat Aug 22 09:58:43 EDT 2015
Den 2015-08-22 kl. 15:38, skrev David Froble:
> Johnny Billquist wrote:
>> 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???
>
> Not at all. Did you miss the "or whatever"? What I'm saying is that you
> used a poor piece of code to demonstrate when "volatile" might be required,
> and what I'm saying is if code follows the manual "volatile" would not be
> needed.
For some specific examples of code maybe. Or are you saying that
"volatile", in general terms, never should be needed? That is
wrong, of course.
>
> If you use QIO, you're saying "I don't want to wait for this operation to
> complete, so tell me when it does". To then attempt to do anything
> concerning the operation before being told it's complete is, according to
> the manual, improper.
More information about the Info-vax
mailing list