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
Previous text:
2003-02-05 20:35: 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.
In your example would the synchronized(bar) case be a compile time or run time error? Actually, it can't be compile time since the variable you want to lock might be run-time specified. As a matter of fact, doesn't the requirement of 'synchronized' declaration limit the usage area quite a lot?
I mean, say you have a method that is called from any thread:
void process_something(mixed var) { synchronized(var) { process ... } }
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. It should just work since there is no inherit need to do anything before "locking" the variable. Sure, you can pre-allocate a mutex but how would that help? Would each svalue contain a pointer to a mutex? That makes no sense since a pointer typically would use the same amount of memory as a mutex lock - how would you indicate that an svalue has a mutex in a way that makes the "preallocate mutex" make any sense?
/ David Hedbor