If you're talking Cocoa, the mutex functionality there is provided by NSLock
and NSRecursiveLock
.
In order to properly protect non-atomic resource, you need these mutexes, lest multiple threads may try to change the data at the same time (leading to corruption) or use the data in a half-changed state (leading to invalid data).
Your code would look something like this:
static NSLock session_id_lock;
static unsigned int session_id = 1000;
- (int) generateSessionID{
int new_id;
[myLock lock];
new_id = session_id++;
[myLock unlock];
return new_id;
}
If you're not using Cocoa (or what little Cocoa programming I remember from my brief interlude with an iMac is so dimly remembered that it's near useless), just use the concept, translating it to whatever language or framework you have:
- lock the mutex before using or changing a protected resource.
- use or change the resource.
- unlock the mutex.
- bonus advice 1: lock the mutex as late as possible and unlock it as soon as possible.
- bonus advice 2: only lock what you need so you avoid unnecessary delays.
Explaining that last point some more: if you synchronise on self
for two totally unrelated things (say a session ID and a user ID), they will block each other despite the fact that it's not necessary to do so. I would prefer two separate mutexes to keep the granularity low.
Of course, if you only have a mutex on the session ID alone (but see below for caveat), feel free to use synchronized(self)
but I'd prefer to do it my way so I wouldn't get caught out adding another protected resource later.
In any case (this is the caveat mentioned), you will probably find that synchronising on self
would not adequately protect a static variable, which would be shared across multiple objects. The mutex should belong to the data rather than whatever is using it.