Even in that case the declaration for the variable ought have some sort of flag that it has a mutex, i.e. that the mutex still is declared in one way or the other. E.g:
synchronized mapping foo; mapping bar; ... void f() { synchronized (foo) {...} // Ok. synchronized (bar) {...} // Error: bar doesn't have a mutex. }
There are two reasons for this requirement: As I've said earlier it avoids silently getting mutexes on the wrong things when one happens to mixup variables. Another reason is that it allows more efficient implementation since the space for a mutex can be allocated at compile time. (Note that the proposed solution with a weak mapping is prone to cause gc overhead since the locked things can't be refcount garbed.)
/ Martin Stjernholm, Roxen IS
Previous text:
2003-02-05 16:36: Subject: synchronized
Well, I think it would be unfortunate if it blocks using "synchronized" as a keyword or metaprogram in the future. I'd like something like this:
class X { synchronized (store_mutex) {
Yes, me too. It could possible be a global definition for now, working inside functions.
Do you mean an implicit mutex creator?
I don't know if implicit is the right word to use. But I suppose so...
If so, do you actually think it's such a gain to not have to write the mutex declaration that it's worth the risk of silently getting more mutexes than you really want?
Yes. I often want to lock a single variable, or a single object. It seems logical to lock that variable, or the object by giving that to synchronized(). I don't see that step very far from using the synchronized keyword, and locking the mutex without calling lock().
/ Mirar