shared/unshared classes

[Jonathan M Davis]

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
> > <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.
> 
> 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