Steven Schveighoffer wrote: >On Sat, 19 Feb 2011 21:55:53 -0500, Jonathan M Davis ><[email protected]> 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
signature.asc
Description: PGP signature
