Use lighter atomic counters instead of mutexes

[tsenart]

Where appropriate, it makes sense to use lighter weight atomic counters
instead of mutexes.

[davecgh]

We have to very careful when using atomic counters as they must be byte aligned within the struct. If you look back through history you'll find commits that specifically moved away from the atomic package for some things.

One such commit is e5a1c6e which specifically changed the byte counters you have done here as it will cause a panic.

As I stated in that commit, I really don't want to rely on having to keep track of struct alignment to prevent run-time panics.

Given the above, I'm going to vote no for this pr. It would make the code too fragile such that changing the struct definition could easily introduce run-time panics the programmer is extremely unlikely to notice.

[tsenart]

Very well, assuming you want to support those architectures, I fully agree that its preferable to use a sync.Mutex for bytesReceived and bytesSent instead of keeping track of memory alignment.

For numClients, however, it is my understanding that we can safely use 32bit atomic ops.

Just for future reference, I'm including some relevant comments present in the sync/atomic/doc.go file.

// BUG(rsc): On x86-32, the 64-bit functions use instructions unavailable before the Pentium MMX.
//
// On non-Linux ARM, the 64-bit functions use instructions unavailable before the ARMv6k core.
//
// On both ARM and x86-32, it is the caller's responsibility to arrange for 64-bit
// alignment of 64-bit words accessed atomically. The first word in a global
// variable or in an allocated struct or slice can be relied upon to be
// 64-bit aligned.

[tsenart]

I have reduced the change set accordingly.

[davecgh]

OK

[davecgh]

This has been rebased and merged as commit 2afc5a0.