Update: I think I know what I (and AnonymousMonk?) were missing. It is this section of the RFC:

Note that value modification is limited to assignment. Functional modification requests - such as "Change X to be Factorial(X)" - are specifically ruled out. Allowing them would force the use of system wide synchronization interlocks.

What this means (if I interpret it correctly) is that the database only stores values and retrieves them. Any new value applied is simple a new value, it can have no relationship to the previous value!

Which makes it totally inapplicable for the purpose of sharing objects between threads.

---

Your right, I didn't read it thoroughly, just scanned it a couple of times. Like most RFCs, I find the language chosen--probably for very real reasons of avoiding associations with any particular programming language, OS or other pre-existing system--makes for extremely tedious and difficult reading.

However, given your precis, I have given it another read and ... well, I still not convinced. Certainly not as a realistic mechanism for object sharing in Perl(5?). I'll try to outline why.

Two threads have access to a single shared scalar X. Each thread needs to increment X by 1. The sequence of operations required by each thread to do this is:

1. Enqueue (Selector) request:

   Selector: X; (DBMP)ID: n; SequenceNo: s;

2. Process all messages in the Q, in sequenceNo order,

   until the just queued message is top of the Q.

3. Return the current value of X to the calling code.
4. Add 1 to the value returned.
5. Enqueue (Assignment) request:

   Selector:X; ID:n; SequenceNo:s+m; Value: v;

6. Process all messages in the Q, in sequenceNo order,

   until the just queued message is top of the Q.

7. Enqueue update (Assignment) message other thread.

Now look at (one of) the different sequences in which these action can occur on two sequentially run, pre-emptive threads. At the start of the following assume that both threads copies of the DB are synchronised and contain one selector X with a value of 2. The action to be performed by both threads is to increment the shared variable X by 1.

Thread 1                Thread2
X1=2                    X2=2
=================================================================
Step A -> "S:X:1:1"
Step B -> 1 message (ours) to process.
Step C -> return 2
------------------------------------------- Timeslice
                        Step A ->  "S:X:2:4"
                        Step B -> 1 msg to process
                               -> "S:X:2:4"
                        Step C -> return 2
------------------------------------------- Timeslice
Step D -> 2+1 = 3
Step E -> "A:X:1:7:3" 
Step F -> X1=3
       -> Enqueue "A:X:1:9:3" -> T2
------------------------------------------- Timeslice
                        Step D -> 2+1=3
                        Step E -> "A:X:2:11:3"
                        Step F -> 2 msgs to process
                               -> "A:X:1:9:3"  -> X2=3
                               -> "A:X:2:11:3" -> X2=3 !!!Bang!!!
=================================================================
[download]

At point !!!Bang!!!, both threads think they have incremented X, but both threads have a value for 3 for X?

Maybe I'm being thick tonight (always?), but I don't read anything explicit or implied in the RFC that deals with this overlap?

Even if I am missing something, and the RFC does deal with this (which I think it must but I don't see how?), then if every simple increment or decrement of a shared value is going to require the (minimum) 7 steps I've outlined above (skiping over that:

• each transmission to another thread requires positive confirmation;
• the number of transmission/wait for receipt cycles grows with each additional sharing thread;
• that your statement that "Of course all data referenced by data in the "Database" must be replicated themselves and stored in the "Database"." means that every value in every thread must be shared between every thread (including all code) in order to deal with closures; globals; lvalues etc.

)

if this was implemented, I think that the phrase that comes to mind to describe it is "slow as molasses".

I know I missing something vital here--but what?

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.