No, that's one place where it definitely can't be. I'd like them to be allocated next to the variables that need locking, even though that
Huh? Allocated "next to the variables"? What do you mean with that?
/ David Hedbor
Previous text:
2003-02-06 01:03: Subject: synchronized
I don't have a major problem with that. And yes, the weak mapping solution is a hack / temporary solution rather than what I'd really like to get implemented.
Can't think of any other way to associate mutexes with values without incurring some overhead on values where they aren't used.
Now everything calling this method would have to use 'synchronized' variables. Since it's impossible to know WHAT would be calling this method at compile time, it has to be a runtime error. I don't like that at all.
Why not? I don't think it's that different from the runtime type checks everywhere. What's the use of silently promoting unsynchronized values to synchronized ones? When you create the value you ought to know if you plan to use it synchronized or not. If a value starts out as unsynchronized the risk is obvious that it also is used without proper locking by the code that created it.
It should just work since there is no inherit need to do anything before "locking" the variable.
There's no inherent need to declare a variable before using it either, but most languages demand it anyway since it provides means to check for various errors.
Would each svalue contain a pointer to a mutex?
No, that's one place where it definitely can't be. I'd like them to be allocated next to the variables that need locking, even though that has its limitations, e.g. the case you brought up where a plain synchronized value is passed around would need it to be wrapped:
class SynchVal { synchronized mixed val; }
void process_something (SynchVal x) { synchronized (x->val) {...} }
Although a bit clumsier I don't think that's a bad thing since it provides good compile time and runtime checking.
/ Martin Stjernholm, Roxen IS