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) { mapping store = ([]); int last_id = 0; }
int add (mixed data) { synchronized (store_mutex) { store[++last_id] = data; return last_id; } }
mixed get (int id) { // This generates a compile time or runtime error: store is // accessed without holding store_mutex. return m_delete (store, id); } }
But it's not necessarily true that a Thread.synchronized has to interfere with this.
But this would work as implicit-lock creator too, so I think it's nice and does what you want<tm>:
Do you mean an implicit mutex creator? 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? To me it seems like a variant of the BASIC style implicit variable declarations.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-02-05 09:03: Subject: synchronized
It would only harm if we want synchronized() to have some other semantics in the future. Do we?
But this would work as implicit-lock creator too, so I think it's nice and does what you want<tm>:
syncronized("superlock") { ... } // global keyword :)
class Foo { syncronized(Foo) { ... } // class-global lock syncronized(this_object()) { ... } // object-global lock
mapping m; ... syncronized(m) { ... } // only blocks on the same m instance ... m=copy_value(m); // ignore all current threads working :)}
It's just sad you can't use it like this (or can you?):
class Bar { syncronized my_func() { ... } or syncronized(this_object()) my_func() { ... } }
/ Mirar