If a GeneralShardedCounter is accessed often enough, the memcache representation will get out of sync.

Running 100-1000 parallel operations incrementing the counter (and occasionally reading its value) results in memcache reaching a level between 0.1% and 1% higher than the actual sharded counter value. I've tested this numerous times on 10,000 operations; the counter reaches 10,000 as the operations (task queue tasks) are spawned, but the count of operations finished (each operation increments the counter on exit) reaches anywhere from 10,001 to 10,100 or thereabout.

If the memcache value expires, and any number of operations has just incremented a shard but not yet incremented memcache, a call to get_count will count the just-incremented shards, store the value in memcache, and then memcache will be incremented, leaving those operations counted twice, with a resulting higher count in memcache.

My workaround is to invalidate the cache if I want to get a more "accurate" number, but I think the memcache results here should be taken as no more than a hint.

This sample is not runnable due to a missing file:

counter.html