Ensure atomicity of user_save within hook_node_delete
user_save() itself is likely to be guaranteed atomic. You're running innodb or equivalent, right?

However, you have no guarantees that the user isn't altered between your user_load() and user_save(), which can cause a race condition. There lock.inc for that. 


  A database-mediated implementation of a locking mechanism.


This is very unlikely though, and if this happens to you often and regularly, you likely have a problem elsewhere in your code.

However, not even that can protect you from other parts of the code, in a parallel request, loading up the user, modifying it, and saving it back, in between your calls. For better or worse, you can't reasonably guarantee that no other piece of code, such as contributed modules, modifies your users.

Suggested options:


Modify the field value directly like UPDATE [table] SET [field] = [field] +/- [value]. Then you can rely on the DB's underlying mechanisms for atomicity.
Accept a small risk of failure. Run a hourly cron job to recalculate values, correcting for mistakes.
Don't use a user field for this data. Either use a custom entity, or directly manage a custom table. Force all updates through a lock mechanism.