[RC5] LIFO? Is this true?

Stephen Berg sberg at gccweb.net
Fri May 8 01:54:49 EDT 1998


Ok, first my disclaimer, I'm not a programmer unless you consider
REXX a programming language, but I just had a thought on this
particular idea.

Instead of a buff-in and a buff-out, why not have just a single
buffer file.  Which in human terms could look like this (I'm sure
this would be in hex code and not ascii but you should get the idea):

Block			Status		Partial Offset
683314F0:D0000000	Done		
683314F0:E0000000 In Progress		(an offset for the
clients progess)
683314F0:C0000000	Waiting
683314F0:F0000000 Waiting

When the client fetches/flushes/updates, it could just rewrite the
block address, change the status and the offset for in progress
blocks.  Then the only time you'd have to worry about stagnant blocks
is if you changed your buffer size values.  If I buffer 80 blocks,
they are all in one file, and each has a status value for how much
progress I've made through those 80 blocks.  If I run out of blocks,
the client could generate random blocks as usual and just add those
block addresses at the end of the file.  When it updates next it can
report them and delete those entries in the buffer file.  

I realize this would mean lots of work for the coders to change the
buffering method but my personal thought (of a non-programmer
remember) is that this would cut us down to one buffer file, and get
rid of the FIFO vs. LIFO contention.  And maybe in the programming
world this is just a no way-no how-it ain't gonna happen kind of
thing, I just had the thought and figured I toss it out to see how
severly I get hammered for it. =:-)

On Thu, 07 May 98 18:33:18 -0600, gindrup at okway.okstate.edu wrote:

>     On a semi-related note...
>     It recently struck me that there would be better symmetry if instead 
>     of checkpointing, partial blocks were written to the buff-out and 
>     blocks in the buff-in weren't deleted until all of their subparts 
>     were in the buff-out.  The symmetrical relation is to that of the 
>     subspaces not being marked as done until all the little blocks in 
>     them are marked as done...  As a coding detail, I would set this up 
>     in the same way that requested blocks are set up: what's the log 
>     (base 2) of the number of keys you want in a checkpointing write to 
>     the buff-out?  The buff-in would fluff out to allow all the little 
>     block parts to be represented separately.  Partially completed 
>     blocks would need to be selected preferentially to entirlely 
>     untouched blocks.  Blocks should be (or possibly already are) 
>     datestamped and old blocks should receive preference.

                            Stephen Berg
//- USAF Instructor  -/-  Team OS2 Member  -/-  Merlin Beta Tester -//
//- Home = sberg at gccweb.net // Work = berg at trs333.kee.aetc.af.mil  -//
//-                    http://www.gccweb.net/sberg/                  -//
//-   If you build a better mousetrap, someone will genetically    -//
//-                     engineer a better mouse.                   -//

--
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest



More information about the rc5 mailing list