On 2012-11-12, 15:11, Jacob Carlborg wrote:
On 2012-11-12 12:55, Regan Heath wrote:
On Mon, 12 Nov 2012 02:30:17 -0000, Walter Bright
<[email protected]> wrote:
To make a shared type work in an algorithm, you have to:
1. ensure single threaded access by aquiring a mutex
2. cast away shared
3. operate on the data
4. cast back to shared
5. release the mutex
So what we actually want, in order to make the above "nice" is a
"scoped" struct wrapping the mutex and shared object which does all the
"dirty" work for you. I'm thinking..
// (0)
with(ScopedLock(obj,lock)) // (1)
{
obj.foo = 2; // (2)
} // (3)
// (4)
(0) obj is a "shared" reference, lock is a global mutex
(1) mutex is acquired here, shared is cast away
(2) 'obj' is not "shared" here so data access is allowed
(3) ScopedLock is "destroyed" and the mutex released
(4) obj is shared again
I think most of the above can be done without any compiler support but
it would be "nice" if the compiler did something clever with 'obj' such
that it knew it wasn't 'shared' inside the the 'with' above. If not, if
a full library solution is desired we could always have another
temporary "unshared" variable referencing obj.
I'm just throwing it in here again, AST macros could probably solve this.
Until someone writes a proper DIP on them, macros can write entire software
packages, download Hitler, turn D into lisp, and bake bread. Can we please
stop with the 'macros could do that' until there's any sort of consensus as
to what macros *could* do?
--
Simen
