Explanations for the labels, given that this is your first PR:

Marking as "needs docs" because the doc string should be included into the documentation document (HTML/PDF).

Marking as "needs news" because there's no news entry added, see NEWS.md.

The doc strings may be included into the built docs by adding the lines for the new types around here:

Why introduce a new PaddedSpinLock rather than improve the implementation of SpinLock?

If you are including the SpinLock in a struct, you often will want to use the other fields of the struct as padding.

Why introduce a new PaddedSpinLock rather than improve the implementation of SpinLock?

The unpadded SpinLock may be useful in some situations: It's quite a bit smaller than the padded one. I could imagine, for example, someone putting a SpinLock on every vertex of a graph, and being sensitive to the size of the SpinLock. In that case, a little false sharing might be OK. I didn't want to break anyone's code, so I made a new lock..

If you are including the SpinLock in a struct, you often will want to use the other fields of the struct as padding.

I'm not sure whether that's true.. As I understand it (and I could be wrong) a SpInLock is a mutable struct, so when you include it in another struct, the other fields of the containing struct don't act as padding. All that's stored in the containing struct is a pointer to the SpinLock, and if two such SpinLock's end up on the same cache line, you'll get false sharing. This kind of thing is more likely when using, for example, JEMalloc than some other malloc implementations, since JEMalloc will pack 8-byte objects together on the same cacheline or page.

Probably want to add a public statement for the new types. Around here:

Thanks for the various suggestions and the help with process.

Pending review comments LGTM!

The test failures look real.