> > 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
competative.
> 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
> > http://www.cia-g.com/~sietch/
> +-----------------------+---------------------------------------+
> | Nathan Bryant | Unsolicited commercial e-mail WILL be |
> | nathan@burgessinc.com | 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> ### jeezfrk@interealm.com $$$$$$$$ Keep Treasures in Heaven - Y'shua $$