[lkml]   [1997]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Async IO through clone() alone
    Nathan Bryant writes:
    > On Mon, 27 Jan 1997, Greg Alexander wrote:

    > > aren't you over-complexicating? All you need for threading is clone(2) and
    > > mmap(2).

    I think he is also.. but in a subtle way.

    > Not at all. Firstly, when you do clone() the new thread shares its address
    > space with the first one, so you don't need mmap() for shared memory.

    Point noted, certainly..

    > Secondly, any program which has multiple threads accessing shared memory
    > has to have a way to synchronize access to that shared memory.

    Nope. Not necessarily. The information from a thread is one-way: back.

    Remember.. bottlenecking on a resource/communication-point is the reason for
    mutex. No other process requires mutex.

    All these threads are doing is being

    a) suspended in a pool of created-but-not-allocated threads
    or b) blocking [so nicely] on the "deferred" IO return
    or c) writing their results in shared mem detailing the results
    or d) inducing a signal to wake the central library to new facts

    The central library system (the "main-thread" system) can use its *ONE* handler
    to poll/multiplex all completed-call threads. This *DOES* require a thread to
    have --one-- byte somewhere properly changed *after* it is done.

    Again.. a one-way mutex is needed only for the "HEY YOU.. LOOKIT WHAT I DID!!"
    call. Even then.. a "signed and sealed" code-byte in the thread's own portion
    of "shared" memory can confirm a completion-result... and no other thread can
    be allowed to make that "signed and sealed" byte flip to its new value.

    Iff memory is properly shared, the entire result-information is visible and
    perfectly received, even in a signal handler. Heck.. a new IO request could
    be sent out for a waiting thread.

    In essence.. a thread can be manipulated and woken up entirely at the leisure
    of the central library calls.

    > If two
    > threads need to write to the same area of memory at the same time, and you
    > don't use any sort of locking, you're screwed.

    Yep. No need for it, though. That is needed only when threads must compete
    for some central object. Finishing their Async tasks is not inherently

    > Locking can be accomplished by having one thread wait to access the
    > shared memory until the other thread is done. The way the pthreads
    > library (aka LinuxThreads) accomplishes this is by calling sigsuspend() to
    > wait for a signal which gets sent when the other thread is done accessing
    > the shared data.

    Signals are *ideal* for fork/exec calls and fully independent programs. They
    are a rather heavy-handed a mechanism for lightweight clones floating around.

    > Since you can't receive a signal while you're in a signal handler, you
    > have to sit in a tight loop doing nothing while you wait for access. And
    > we all know that sitting in tight loops doing doesn't do good things for
    > your CPU idle time ;)

    I agree with your presumption. Threads aren't processes, and locking by
    signals is impossible to consistently do.

    > What I meant was, Linux won't have POSIX-compliant asynchronous I/O until
    > it gets POSIX-compliant signals.

    AHA! Linux could triumph, from what I see. Are there some hardware issues
    (cache-coherence?) that I'm missing out on?

    It is documented that two parties can communicate as long as the "I am done!"
    signal is unmistakibly delivered in sequence with global-storage manipulation.

    In simplest terms.. if we both can messily edit our chalkboards but are allowed
    to fire flashbulbs when we're done ... we can cooperate and communicate without
    any overruns or interference. Our communication is fully "serialized."

    If you have N objects competing over one thing (dev interrupts, multi-kills,
    some exclusive control over a server) ... then yes they require special
    locking. There's no reason to do it for enumerated pre-formed threads.
    That's the key.

    > > Greg Alexander
    > >

    > +-----------------------+---------------------------------------+
    > | Nathan Bryant | Unsolicited commercial e-mail WILL be |
    > | | charged an $80/hr proofreading fee. |
    > +-----------------------+---------------------------------------+

    -=- <<I give only *my* thoughts the wierd ob\l|v/iousness they deserve!>> -=-
    / (O)ne doesn't own what one doesn't have ... --X-- "God is dead." -Nietzsche
    \ what one must give up, one cannot own.. / | \ "Nietzsche IS dead." -God
    [DoubleTalks, SingleThoughts, AntiFaiths] | <>< [Rome falls anew!]
    ### C>H> ### $$$$$$$$ Keep Treasures in Heaven - Y'shua $$

     \ /
      Last update: 2005-03-22 13:38    [W:0.023 / U:8.756 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site