shared/unshared classes

[Johannes Pfau]

Steven Schveighoffer wrote:
>On Sat, 19 Feb 2011 21:55:53 -0500, Jonathan M Davis
><jmdavisProg at gmx.com> wrote:
>
>> On Saturday 19 February 2011 18:26:25 Steven Schveighoffer wrote:
>>> I was working on an I/O library that I plan to use in development,
>>> and possibly submit to phobos, and I thought of this case.
>>>
>>> A standard file can be shared or unshared.  In C, since there is
>>> no notion
>>> of shared/unshared, everything is shared.  So any writes/reads from
>>> a FILE
>>> * lock the object.
>>>
>>> But in D, we can avoid those locks when the file is unshared.
>>> However, this means I have to write two pretty much identical
>>> functions for each call.
>>>
>>> Is there an expected way to do this?  I've really avoided doing
>>> anything with shared or threads since the new concurrency model
>>> came out, but with
>>> I/O, I'll have to deal with it.
>>>
>>> I think a logical thing to do would be to have the shared version
>>> of the function call the unshared version after locking the
>>> object.  Is that a good idea?  Is the correct way to do this to
>>> mark the shared function synchronized, and then cast 'this' to
>>> unshared to call the other function?  Does this automatically
>>> happen with shared functions?
>>
>> I would point out that per TDPL, either an entire class is
>> synchronized or none
>> of it is. You don't synchronize individual functions. Now, I don'
>> think that
>> that's the way that it's implemented at the moment, but that's the  
>> eventual
>> situation as I understand it. So, your class shouldn't have a
>> mixture of synchronized or unsynchronized. According to TDPL, it's
>> illegal.
>>
>
>OK, I kind of remember that now.  So that means, I need to create two  
>identical hierarchies, a synchronized one and a non-synchronized one?
>
>I think what I'll do for now is write the non-synchronized versions,
>and then see about maybe automating the synchronized parts.
>
>-Steve

Creating two types, one synchronized, one not, doesn't sound like a
good solution. If you need fine grained locking you can still do that
manually (mark the function as shared, use the synchronized statement
in the function). When I tried to do that for my std.signals
replacement (which reminds me that I finally have to propose it for
review) I found quite some bugs in the shared system. There's no
shared signal because of those:

http://d.puremagic.com/issues/show_bug.cgi?id=3733
This one is very annoying and I think I hit one or two cases where
even the workaround didn't work.

IIRC operators couldn't be overloaded with shared functions.

Then I hit this issue:
http://lists.puremagic.com/pipermail/digitalmars-d-learn/2010-November/019858.html
And I gave up ;-)
-- 
Johannes Pfau
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20110220/1ad91e4e/attachment-0001.pgp>