svn commit: r252032 - head/sys/amd64/include

[Gleb Smirnoff]

On Sun, Jun 23, 2013 at 10:33:43AM +0300, Konstantin Belousov wrote:
K> On Sat, Jun 22, 2013 at 06:58:15PM +1000, Bruce Evans wrote:
K> > So the i386 version be simply "addl; adcl" to memory.  Each store in
K> > this is atomic at the per-CPU level.  If there is no carry, then the
K> > separate stores are equivalent to adding separate nonnegative values and
K> > the counter value is valid at all times.  If there is carry, then the
K> > separate stores are equivalent to adding a negative value followed by
K> > a larger positive value.  The counter transiently goes backwards, but
K> > no information is lost and the counter is eventually set to the correct
K> > forward-going value.
K> 
K> This is quite interesting idea, but I still did not decided if it
K> acceptable.  The issue is that we could add the carry to the other
K> processor counter, if the preemption kicks in at right time between
K> two instructions.  I did not found any argument why would it be
K> wrong, the races for fetch operation seems to be the same with either
K> local update method.

This would be wrong since update isn't locked. Thus, if we are put on
other CPU between two instructions, and in second instruction updating
another CPU counter simultaneously with the original CPU we were on,
then we are losing an update.

Yes, the probability of such event is extremely low, but still possible.

The idea on counter(9) is that although fetching might be not precise,
the internal value of a counter is consistent and doesn't lose even a
single update. This would allow later to use counter(9) as a cheap
reference counter.

-- 
Totus tuus, Glebius.