[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Threads !!



Bret,

Haven't done any threaded programming in the UNIX world, but in OS/2 the
'multithreaded libraries' are actually the same libraries as the 'single
threaded libraries', *except* that the 'multithreaded' versions are
guaranteed(?) to be 100% re-entrant. This might require to serialize
access to certain data objects within the library, which of course may
slow down performance of a specific thread. It is still worthwhile,
since a multithreaded application (with a least a *little* bit of
thought behind) will be so much quicker.

Something I forgot to mention is that multithreaded applications can
gain a lot of speed on a single processor as well. See our earlier
example: When one thread is waiting for hardware, another thread will
execute.

Regards
Gustav

Bret Hughes wrote:
> 
> 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
> > >         ignatz dminet com
> > >
> > > --
> > > To unsubscribe: mail redhat-list-request redhat com with "unsubscribe"
> > > as the Subject.
> >
> > --
> > pgp = Pretty Good Privacy. To get my public pgp key, send an e-mail to:
> > pgpkey schaffter com
> >
> > Visit my web site at http://www.schaffter.com
> >
> > --
> > To unsubscribe: mail redhat-list-request redhat com with "unsubscribe"
> > as the Subject.
> 
> --
> To unsubscribe: mail redhat-list-request redhat com with "unsubscribe"
> as the Subject.

-- 
pgp = Pretty Good Privacy. To get my public pgp key, send an e-mail to:
pgpkey schaffter com

Visit my web site at http://www.schaffter.com



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]