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

To set you at ease: All AM-Posts in our thread are from me.

I'm thinking you are hypocritcal. First you complain about noncoordinated replicas. I show you then that replicas can be so coordinated, that they are EXACTLY like a shared instance, including all problems. Now you complain about these problems because you would like a middle ground. Then I show how such middle ground can be reached with only one extra message. Now it's the complexity. Fear not! This is possible too by distributed transactions. Think about this: A key points to a value, which as key points to the next value, and so on until pointing to the first key. Linked List as Ring. Nothing new. Who closes the Ring (commit)? If one of these values does not participate (points to itself) can the Ring be closed (abort)? No value decided=lock? And that is only with get/set!

The essential Good Thing is It's tunable!!

BTW I know about Fibers. The complexity of them is hidden in the OS. For instance: If a Fiber is preempted by another process the rescheduling must not choose its partner.

  • Comment on Re^10: Passing globs between threads (Updated).

Replies are listed 'Best First'.
Re^11: Passing globs between threads (Updated).
by BrowserUk (Patriarch) on Oct 09, 2004 at 04:02 UTC
    I'm thinking you are hypocritcal.

    Shame. I was continuing to enjoy this thread.

    FWIW: I took you seriously enough to look at trying to implement this is Perl. So far, the information you have provided, or perhaps it's just the information I have succeeded in extracting from your posts (ie. My limitations), mean that I still cannot see how to do it effectively. Complexity is not an issue, I just don't see how to do large parts of this.

    Update: My promised update re:Fiber*s. Implementing Co-Routines using Fibers.

    * Thanks to bmann

    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]
      Did I have used a word that I shouldn't (native german speaker(and no sleep to boot))?

      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.

[reply]
        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
[reply]
[d/l]

In Section Seekers of Perl Wisdom