One additional point from a not very experienced programmer is that a
program must be written to utilize threaded behavior. Just compiling
and linking against a particular library won't make a monothreaded
program multithreaded. My guess is that the different libraries will
alter the behavior or enforce certain programming techniques but I
really don't know for sure. Help any one?
I know in java a syncorization mechanism exists to help ensure that two
or more threads won't modify the same data element or not get the value
updated if another thread modifies it.
Bret
Gustav Schaffter wrote:
>
> 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.
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
