Re: [PATCH] binary or instead of logical in timer sync

[Steven Rostedt <srostedt@redhat.com>]

Keir Fraser wrote:
>
> On 3 Aug 2006, at 04:17, Steven Rostedt wrote:
>
>> The reading of a timer is determined if 1. the hypervisor is not 
>> currently updating it (where it sets the LSB of the version) or 2. 
>> the kernel didn't finish reading it before the hypervisor updated it 
>> (the kernel version doesn't match the hypervisor version).
>>
>> But the current code doesn't test the above case. Instead, by using a 
>> binary or instead of a logical one, it would only repeat if the 
>> hypervisor was updating  __and__ we read the version before it 
>> started updating (or we read it before we started updating, but the 
>> hypervisor finished updating between the first part of the or and the 
>> second check).
>
> I don't believe there is a bug here. Are you suggesting that the 
> binary or, used within a logical predicate, behaves as a logical and? 
> That doesn't make sense.

Crap, you're right.  I was debugging a problem with a bad timer, and saw 
that a binary or was being used for a logical case and just assumed that 
it was a bug.  Since it is common to see bugs like this using  & instead 
of &&.  So being late (and very hot here) I jumped the gun and posted 
the patch.

>
> The only reason for using binary operators in those predicates is to 
> avoid extra branches in the generated code which would probably be 
> generated to follow the short-circuiting semantics of the logical 
> operators. In fact, I think a smart optimising compiler would generate 
> the *same* object code regardless of whether we use binary/logical or 
> (but I don't believe gcc is that smart yet!).
>  

With some sleep behind me I see your point.  You're using the binary or 
to let the math determine the branch instead of logical jumps.

Makes sense,  sorry for the noise.

Hmm, perhaps a comment there is in order so another tired, hot and 
sticky programmer doesn't make the same mistake as I did :(


-- Steve