On 15.11.2012 11:52, Manu wrote:
On 15 November 2012 12:14, Jacob Carlborg <d...@me.com
<mailto:d...@me.com>> wrote:
On 2012-11-15 10:22, Manu wrote:
Not to repeat my prev post... but in reply to Walter's take on
it, it
would be interesting if 'shared' just added implicit lock()/unlock()
methods to do the mutex acquisition and then remove the cast
requirement, but have the language runtime assert that the object is
locked whenever it is accessed (this guarantees the safety in a more
useful way, the casts are really annying). I can't imagine a
simpler and
more immediately useful solution.
How about implementing a library function, something like this:
shared int i;
lock(i, (x) {
// operate on x
});
* "lock" will acquire a lock
* Cast away shared for "i"
* Call the delegate with the now plain "int"
* Release the lock
http://pastebin.com/tfQ12nJB
Interesting concept. Nice idea, could certainly be useful, but it
doesn't address the problem as directly as my suggestion.
There are still many problem situations, for instance, any time a
template is involved. The template doesn't know to do that internally,
but under my proposal, you lock it prior to the workload, and then the
template works as expected. Templates won't just break and fail whenever
shared is involved, because assignments would be legal. They'll just
assert that the thing is locked at the time, which is the programmers
responsibility to ensure.
I managed to make a simple example that works with the current
implementation:
http://dpaste.dzfl.pl/27b6df62
http://forum.dlang.org/thread/k7orpj$1tt5$1...@digitalmars.com?page=4#post-k7s0gs:241h45:241:40digitalmars.com
It seems to me that solving this shared issue cannot be done purely on a
compiler basis but will require a runtime support. Actually I don't see
how it can be done properly without telling "this lock must be locked
when accessing this variable".
http://dpaste.dzfl.pl/edbd3e10
