I'm pretty volatile doesn't ensure atomic access, it just prevents the compiler from optimizing those variables out because it assumes nothing else will modify them. That's why you usually see it used with memory mapped I/O; the compiler doesn't know the machine will modify that memory location, and only sees that the code itself doesn't.

@Neal, yes you're absolutely correct. Volatile does not ensure atomic access which I incorrectly alluded to.

Volatile declaration would solve only a part of the problem. Not only is it used to make sure the register is read instead of using an optimised cache, it can thus help when ISRs can modify globally defined variables. In the case of this library here, perhaps a mutex may help regarding atomic access? My understanding of a volatile variable is as explained, that it prevents compiler optimisation, hence why I think it is only a part of the solution. If we were to analyse this code, I dont think such guards are necessary? pulsewidth and period are only modified by one ISR each anyway! Instead I may just move those two variables to the protected space to prevent some nasty business. Thoughts anyone? Thank you everyone so far for your insight :)