David,
I think the best live example would build on the event driven
application mentioned by Dave here.
Assume that an X application talks to some hardware device, like a
serial port. This application might need to simultaneously:
a) Listen to the serial port (never know when something comes down the
the cable)
b) Send data on the serial port
*and*
c) be responsive to the users mouse and keyboard actions.
As a programmer, see it like this:
The 'main' part of the application interacts with the user. When the
user clicks on a 'connect' button, the application will call a special
api with one of it's parameters being the name of a function in the
application.
The application never calls this function itself (though it technically
could). The api will load this function in a separate 'thread' and the
OS will start executing the thread/function almost as if it was another
application.
The main difference is that (as Dave so well explained) the new thread
shares data with the rest of the application. The 'threaded' function
can also call other functions, that might be called by the 'main'
application as well.
So you see, the programmer must either make sure that all functions are
100% re-entrant or protect them with semaphores or other 'serialization'
mechanisms. The same goes for any shared data objects within the
applications like global variables (shiver ;-) and such.
And as Dave also touched, to communicate between threads in the same
application, the programmer is *strongly* encouraged to use IPC
mechanisms, such as pipes, queues, etc.
One thing more. Think of it like this: All applications contains at
least one thread, which actually is the main application. Some
applications (multi-threaded applications) use more than one thread.
(I used to do a lot of this under OS/2.)
Regards
Gustav
Dave Ihnat wrote:
>
> David D.W. Downey wrote:
>
> > OK, at the risk of sounding like an idiot let me ask the following.
>
> Don't ask, never know.
>
> > If application A is running (the process), the functions that comprise
> > that process are the threads? Or at least if it's compiled using the
> > pthreads library? If so, then what is it from compiling against that lib
> > that changes the functions' attributes from that of "normal" functions
> > like say ptrace() or fopen()?
>
> No. A thread is a stream of control or execution within a program; but
> all threads share the same process space. Another way of looking at it
> is that there are multiple 'processes' running within the constraints
> of an external Unix/Linux process.
>
> The perceived advantage is that each thread is much more "lightweight"
> than a full fork/exec or vfork of a separate process. Also, since they
> share the same address space, inter-thread communication is much less
> expensive, and all threads in a process share data. Threads, to many,
> are more intuitive and sensible in an event-driven application, rather
> than the sequential execution usual in a single "heavyweight" process.
> Also, with a cooperating compiler and system, good use can be made of
> multiple processors via threads.
>
> The perceived disadvantages are that all threads in a process share
> data. You have no protection from a misbehaving thread; in effect,
> imagine that you're running a set of processes on a machine with no
> memory management protection. This means that the author must maintain
> a nice sense of critical code regions, inter-thread cooperation in use
> of shared resources, etc., or things can become...interesting...to
> debug.
>
> For the nitmasters: This is simplified. As usual, there can be
> threadish behavior in traditional heavyweight processes, there are some
> mechanisms to mitigate shared memory issues, etc., etc.
>
> Cheers,
> --
> Dave Ihnat
> [EMAIL PROTECTED]
>
> --
> To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
> as the Subject.
--
pgp = Pretty Good Privacy. To get my public pgp key, send an e-mail to:
[EMAIL PROTECTED]
Visit my web site at http://www.schaffter.com
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
