[elephant-devel] Cached slots

Ian Eslick eslick at media.mit.edu
Sat Sep 27 17:51:32 UTC 2008


Leslie,

A few of the prior messages are proof that my memory is full of holes  
these days, so take this with a grain of salt!  This is very  
unfinished stuff.  Cached operations has been tested minimally  
interactively, but hasn't been verified via test suites nor used in  
any significant way.

As best as I can remember, it should work fine in a "single-user" mode  
or in a read-only mode.  The open problem for concurrent use is making  
cached reads transaction safe in the presence of writes (Alex pointed  
out some of the holes in the original scheme in earlier e-mails).   
Another issue is maintaining the semantics of index operations within  
a transaction, etc.  This is going to be tricky to get right.

There may be some stylized usage modes, but it will take some careful  
thought to make sure any of these work properly in the presence of  
writes and transaction restarts, either concurrent or single-writer.

- Read-only:     I can't see a problem with this

- Single-writer: but only if reading stale data is safe...

- Single-writer w/ guard:  have a persistent 'locked' slot that acts  
as a guard and is touched at the beginning of a transaction by readers  
and written by writers at the beginning and end.  So long as all  
transactions have idempotent memory side effects (which should always  
be the case), this should allow you to maintain transaction semantics  
for the single-writer case.  I'm not confident this actually covers  
all cases though.  If it does work, you should be able to write a  
macro to simplify this; something like:

(with-guarded-instances (:reading instances :writing instances)
    &body body)

should be sufficient.

There is also a 'with-cached-instances' macro there which caches reads  
only during a transaction, which means that all slots are read at the  
beginning.  A write through policy on slots will capture write locks  
appropriately.  I'm also not sure if this covers all cases and will  
require some thought as well.

I'm not up to getting the transaction semantics right anytime soon,  
but we should be able to write some macros that cleanly encapsulate  
any design patterns that we can verify.

Ian

On Sep 27, 2008, at 9:44 AM, Leslie P. Polzer wrote:

>
> Are these supposed to work, or is this unfinished stuff?
>
> -- 
> LinkedIn Profile: http://www.linkedin.com/in/polzer
> Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
> Blog: http://blog.viridian-project.de/
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel




More information about the elephant-devel mailing list