Why s this: object lck = my_mutex->lock(); ... destruct(lck)
so much easier to grasp than:
syncronized(mappingfoo) { }
It's not. Please read the second paragraph of 9697233.
A synchronized methods doesn't get get synchronized with another method at all. I don't understand what you're talking about here.
I'm talking about how synchronized works in Java, since I gathered that's where you got the construct from. But ok, then it isn't a problem but otoh it makes the construct fairly useless; I've yet to see a single case where only one individual function needs to be protected by a mutex.
Which is exactly why the java versions work so well - each synchronized method has their own mutex (obviously).
Java doesn't work like that; please read 8.4.3.6 in the Java spec. Since you say they work so well I assume it wouldn't be a problem for you to give a natural example where that synchronization works?
It's not meant to solve any programmatical error - it's to make the syntax easier / nicer.
Compared to having the mutexes explicit you'd save a single line - the mutex declaration. Seriously, is that worth the bother? I see one risk with it: If one happens to use the wrong variable one will silently get another mutex attached to that one. An error would be much better in that case.
So it'd be another matter if it was a construct where I could declare "these variables may only be accessed synchronized", /.../
Which was one of the suggested additional options I had:
synchronized mapping foo = ([]) ...
You didn't explain that. That'd be nice but fairly difficult to implement. (Note that the Synchronized wrapper class you wrote about in 9696453 doesn't achieve it.)
Then isn't it beautiful that you don't HAVE to use that syntax?
Of course not, but I have my doubts about introducing a syntax that has so obvious limitations. That's why I brought it up. It ought to be possible to do better.
Or why not use it with your explicit mutex variable:
synchronized(my_mutex) { modify var 1 and 2 }
You mean synchronized(a_mutex) would lock a_mutex directly while synchronized(not_a_mutex) would automatically associate a mutex with not_a_mutex and then lock it?
You simply don't like the concept of not seeing the mutex lock and the explicit use of it. /.../
I've never said that. I have nothing against a synchronized keyword and that the _locks_ are hidden by synchronized blocks, but I do have my doubts about having the _mutexes_ hidden.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-02-05 05:58: 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.
Why s this: object lck = my_mutex->lock(); ... destruct(lck)
so much easier to grasp than:
syncronized(mappingfoo) { }
Granted, in the case where synchronized is used with a variable the link is fairly explicit although the mutex itself still is hidden.
Exactly and that is the point - hide the unnecessarily visible code to do the locking. Also when you synchronize a method, it is, as I said in the message you commented, extremely obvious how it works - every call to the method uses the same implicit mutex lock.
I still don't understand what is so unclear / hard about it.
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.
A synchronized methods doesn't get get synchronized with another method at all. I don't understand what you're talking about here.
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.
Which is exactly why the java versions work so well - each synchronized method has their own mutex (obviously). The same goes for each synchronize-statement that is based on a variable.
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.
Of course. It's not meant to solve any programmatical error - it's to make the syntax easier / nicer. I.e saving lines of code an global variables, not improving the code or making it easier not to make mistakes.
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.
Which was one of the suggested additional options I had:
synchronized mapping foo = ([]) ...
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.
Then isn't it beautiful that you don't HAVE to use that syntax? Or why not use it with your explicit mutex variable:
synchronized(my_mutex) { modify var 1 and 2 }
If you read my example carefully you'll see I didn't talk about that but rather "synchronized (mutex) {...}".
Well, it's exactly the same thing, code-wise (except that if you already have a mutex variable one obviously doesn't need to create and store on in a mapping).
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.
I disagree strongly. The synchronized keyword doesn't make anything less "safe", it simply makes it easier when you need some simple mutex locking.
You simply don't like the concept of not seeing the mutex lock and the explicit use of it. That is an ok opinion and you can continue with that belief. Personally I see this feature as a coding simplification, in many ways similar to implicit lambdas.
/ David Hedbor