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
Previous text:
2003-02-05 15:38: 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) { 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