On 14 February 2014 11:17, Jarno Rajahalme <jrajaha...@nicira.com> wrote: > > Access to a shared variable that may change concurrently without any sort > of synchronization should be atomic to protect against "tearing", where the > reader gets a mixture of the old and new versions of the variable. This > could happen for a "long int" on a 32-bit platform (if, e.g., the 8 bytes > span a cache line boundary). Atomic access to a variable for which this can > not happen (e.g., aligned 32-bit int on a 32-bit CPU) compiles to normal > memory access, so there is no overhead. > > In practice it is safe to assume that for an aligned "int" or any pointer > this will not be a problem, so why not make the ofproto_max_idle an int > instead of long long int?
This case had slipped my mind, the only motivation for 'long long int' was that this is the type we use for time in general. Given that we already limit the valid values for this variable, and to address this particular issue, I plan to send out a v3 using unsigned instead.
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
