The synchronized keyword without arguments could possibly block all other threads ("disallow threads"-like). I've had a few programs where I would have been satisfied with that, even if it's a daft solution. :)
Otherwize, a synchronized like
mapping locks_n_stuff=set_weak_flag(([]),1);
mixed synchronized(mixed var, function f) { object lock;
if (mutexp(var)) lock=var; else if (locks_n_stuff[var]) lock=locks_n_stuff[var]->lock(); else lock=locks_n_stuff[var]=Thread.Mutex();
object key=lock->lock(); // lock(1)? mixed r = f(); destruct(key); return r; }
might work, it could take functions as arguments,
void my_func() { syncronized(my_func) { .... } }
/ Mirar
Previous text:
2003-02-05 04:05: Subject: synchronized
I asked how it makes the code more clear, and you responded with that it makes it amazingly clear. Not much of a motivation. I gave at least one concrete case where it isn't: Since there's no mutex name it gets harder to do a grep or similar to find all regions that are synchronized with each other.
Granted, in the case where synchronized is used with a variable the link is fairly explicit although the mutex itself still is hidden.
The synchronized method format makes it so that the format is never accessed by more than one thread at any time.
Yes, but I don't think it helps any that the scope of synchronization is implicit. It becomes easier to just use it with no clear understanding about what other methods it also gets synchronized with. And in my experience it's absolutely essential to have exactly the right scope for each mutex; using the same one for too many functions is just as disastrous as using it with too few.
Synchronizing on a variable makes it the implicit "lock" (i.e anything else synchronizing on that variable will get a lock).
Yes, as long as that else is consciously synchronizing on it; it's still just as easy to forget the synchronize block for the variable somewhere and thus get races on it. I think _that_ is a problem worth solving, not just to get a mutex implicitly declared next to the variable.
So it'd be another matter if it was a construct where I could declare "these variables may only be accessed synchronized", and the compiler would then do all necessary flow analysis and give me errors whenever I broke it. That would be a very useful thing.
Also note "variables"; in almost every case I've had to protect more than one variable with the same mutex. To use the Java synchronized construct for that I'd have to encapsulate them in a small class of their own, which makes it a bit clumsy and incurs an extra unnecessary indirection.
If you read more in the thread you'll see a construct which exactly handles the 'syncronized(variable) { ... }' case.
If you read my example carefully you'll see I didn't talk about that but rather "synchronized (mutex) {...}".
The whole idea is to avoid having to explicedly define mutex variables, which you often need to keep in global variables. If you always had to specify a mutex, that would remove half the purpose.
And I see it as a clear feature to have the mutexes explicit. They are important things. They must get absolutely right for everything to work well. They have global implications that can cause unrelated parts of the program to interact in unexpected ways (which is the common cause for deadlocks). I.e. they really require good attention. Making them implicit seems to me like trying to sweep the problem under the mat.
/ Martin Stjernholm, Roxen IS