in reply to Re^12: Passing globs between threads (Updated).
in thread Passing globs between threads

Did I have used a word that I shouldn't...

You decide? 

Heuchler -- eine Person, die Glauben und Meinungen erklärt, daß er nic
+ht hält

[download]
FWIW: I'm serious. For instance: The distributed transaction idea is from a filesystem that I hope to implement someday. I believe it would be safe as logged and faster than cached. The RFC677 should someday replace DNS. No central point of failure that way. Security is a bitch though.

I agree that the mechanism is probably ideal for databases where the vast majority of accesses are readonly references such as DNS and to a lesser extent filesystems. With these, there are relatively few modifying updates, compared to readonly references and/or overwrites with new (unrelated) values. Modifications have to be authorised, which reduces the overall impact of the locking by combining it with the authorisation mechanism. There is also an inherent performance hit related to network communications or diskIO that means that high performance (in the clock cycles sense) is not a criteria.

I am dubious about it's applicability in the areana of shared variable accesses where (typically) 1/3rd or 1/2 of all accesses are modifications to the current value, accessability is authorisation to modify, and high performance is critical.

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

Replies are listed 'Best First'.
Re^14: Passing globs between threads (Updated).
by Anonymous Monk on Oct 09, 2004 at 07:46 UTC
    I could not detect any consistent "Überzeugung". Only with respect to our topic I mean.

    Did you have read my other Node (titled only (Update))? There I'm explaining, that there is no locking involved. The thread must only have the ability to work in the order of its input-queue.

[reply]

      "Consistancy" -- see last para but one and second point in the first ordered list.

      Even when I could not see how the RFC allowed for modifications (which it doesn't), I allowed for the existance of such a mechanism, but concluded that the overhead would likely be too high for inter-thread shared variable access. Once you explained the mechanism you envisaged, I reached the same conclusion. Seems consistant to me?

      I do truely believe in the ideas that I spout, and I do my very best to research my ideas to some conclusion. That doesn't mean I'm always (or ever) right--that would imply inhuman, infallability. The whole (and only) purpose for my interacting in this way is to find out if I am wrong; so that I may learn.

      There are certain subjects upon which I actively avoid interaction--religion, editors, OSs to name a few--because I have arrived at an opinion that has been tested to the point that I see no purpose in discussing it further. These are fairly few and far between, and exclusively subjective, rather than objective matters. On most everything else I am open to debate.

      Yes. I read the other node. I still see the same problem though. In order to allow for modification x = f(x); in the distributed database, the first thread that needs to read the value for modification has to:

      1. Request ownership; (not described in RFC 677)

        For this step to operate, once this request makes it to the top of the request queue:

        1. the request *must* be forwarded to every other database that has a copy of the variable being owned.
        2. The receiving DBM's will not process this request until the requests come to the top of their request queues.
        3. A positive confirmation of that request must be awaited from each duplicate holder.

        In a networked environment, the outbound requests can be deserialised through broadcasting. The inbound confirmations can arrive in any order. (Both help minimise the delays). In a threaded environment, the recieving threads will not process their inbound queues until they get a timeslice, the sending queue will not be able to receive the confirmations until it gets a time slice. Timeslicing is non-determanistic and unordered. Even if every other thread had an empty inbound queue, it could take several timeslices per sharing thread before a single request/confirmation cycle was complete. The ownership requesting thread would need to block for this entire time.

        And what happens if another thread has dispatched a request for ownership prior to receiving the request from this thread?

        Can't happen you say, because all requests are time-ordered (sequence numbered), therefore, no outbound request can be sent until an earlier inbound request has been fully processed.

        The upshot of that, is that all processing on all threads of all shared (distributed) values must be performed in lock-step.

      2. Request the current value; (Selection)
      3. Calculate f(x);
      4. Request update of the value; (Assignment)

        The distributed notification/confirmation cycle repeats here.

      5. Relinguish ownership; (not in RFC 677)

        And again here.

      Effectively, the timebase (sequence numbers) becomes the cpu clock for all operations in the system that involve shared values.

      To put that in perspective, you would reduce your 2(3 or 4) Ghz cpu to having a clock frequency of a few 10s or hundreds of cycles per second, for any operation that involved shared variables.

      In a networked application like DNS, where changes are often deemed to take days to propogate and if it happens within a couple of hours it's a pleasent surprise, this low-frequency clock cycle is not a problem--but for a cpu-intensive code applications it would be fatal.

      When I mentioned "slow as molassses", I was not exagerating.

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
[reply]
[d/l]
        The fine thing about RFC677 is that it works even when some participate at a later date. For instance:
        Request ownership:
        If the other thread doesn't want to work with this shared value or wants to overwrite it with an unrelated one, it doesn't make a difference if it locks the value or not. So this thread doesn't have to participate. If another thread wants to lock, the lock reply can be earlier or later than the modification message. If it's later the lock has obviously failed. So a modification message instead of a lock grant doubles as lock fail message (And the round trip time is shortened). If it's earlier it must have been even earlier at the other thread. So a lock request instead of a lock grant means the lock failed at the initiating thread, and should be granted.
        Relinquishing lock:
        Because a lock is over a range of sequence numbers, and every value has a sequence number of last modification, every value that has a sequence number greater or equal as the end of the lock range is effectively unlocked because it can be modified by greater sequence numbers. So modifying the value relinquishes the lock automagically. No time necessary.
[reply]

In Section Seekers of Perl Wisdom