On Saturday 19 February 2011 19:12:17 Jonathan M Davis wrote: > On Saturday 19 February 2011 19:01:16 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. > > I'd have to study up on it more to know what the best way to handle it is > (I've generally avoided dealing with shared), but what you'd probably end > up doing is creating a wrapper class which was synchronized. However, you > might be able to get it to just automatically use the right one > (unsynchronized for unshared and synchronized for shared) if you use > templates.
Actually, now that I think about it, we're probably going to want a template of some kind in Phobos which wraps an unsynchronized class with a synchronized one. There are going to be plenty of cases where it would be nice to have an unsynchronized class made synchronized (a prime example would be a container class), and it would be annoying to have to keep creating your own wrappers every time that you want to do that. - Jonathan M Davis
