old-www/FAQ/Threads-FAQ/Problems.html

94 lines
3.4 KiB
HTML

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Linux Threads Home Page: What are the common problems with threads?</TITLE>
<META NAME="GENERATOR" CONTENT="Mozilla/3.0Gold (WinNT; U) [Netscape]">
</HEAD>
<BODY background="GraySea.gif">
<P><FONT SIZE=+3>What are the common problems with threads?</FONT></P>
<UL>
<P>Several problems with threads originate from a classic view and its
intrinsic concurrency complexity.</P>
</UL>
<P>Classic View</P>
<UL>
<P>In many other multithreaded OSs, threads are not processes merely parts
of a parent task. Therefore, the question of &quot;what happens if a thread
calls fork() or (worse) if a thread execve()'s some external program&quot;
becomes problematic: the <B>whole task</B> could be replaced. The POSIX
1c standard defines a thread calling fork() to duplicate only the calling
thread in the new process; and an execve() from a thread would stop all
threads of that process.</P>
<P>Having two different implementations and schedulers for processes is
a flaw that has perpetuated from implementation to implementation. In fact,
some multitasking OSs have opted <B>not</B> to support threads due to these
problems (not to mention the effort needed to make the kernel and libraries
100% reentrant). For example, the POSIX-compliant Windows NT does not to
support threads (Windows NT <I>does</I> support threads but they are not
POSIX compliant).</P>
</UL>
<P>Concurrency Complexity</P>
<UL>
<P>Most people have a hard enough time understanding tasks, never mind
&quot;chopped up tasks&quot; or threads. The first problem while programming
is answering the question: &quot;What <I>can</I> be threaded in my app?&quot;.
That, in itself, can be very laborious (see section on &quot;<A HREF="ProgHeuristics.html">What
kinds of things should be threaded/multitasked?</A>&quot;).</P>
<P>Another problem is locking. All the nightmares about sharing, locking,
deadlock, race conditions, etc. come vividly alive in threads. Processes
don't usually have to deal with this, since most shared data is passed
through pipes. Now, threads can share file handles, pipes, variables, signals,
etc. Trying to test and duplicate error conditions can cause more gray
hair than a wayward child.</P>
</UL>
<P>
<HR SIZE=4 WIDTH="100%"></P>
<CENTER><TABLE CELLSPACING=0 CELLPADDING=0 >
<TR>
<TD>
<CENTER><P><A HREF="Types.html"><IMG SRC="ArrowLeft.gif" ALT="[Left Arrow]" BORDER=0 HEIGHT=40 WIDTH=40></A></P></CENTER>
</TD>
<TD>
<CENTER><P><A HREF="index.html"><IMG SRC="House.gif" ALT="[Home]" BORDER=0 HEIGHT=40 WIDTH=40></A></P></CENTER>
</TD>
<TD>
<CENTER><P><A HREF="Dictionary.html"><IMG SRC="BookSearch.gif" ALT="[Book Search]" BORDER=0 HEIGHT=40 WIDTH=40></A></P></CENTER>
</TD>
<TD>
<CENTER><P><A HREF="mailto:walton@oclc.org"><IMG SRC="MailBox.gif" ALT="[Mailbox]" BORDER=0 HEIGHT=40 WIDTH=40></A></P></CENTER>
</TD>
<TD>
<CENTER><P><A HREF="Support.html"><IMG SRC="ArrowRight.gif" ALT="[Right Arrow]" BORDER=0 HEIGHT=40 WIDTH=40></A></P></CENTER>
</TD>
</TR>
<TR>
<TD><A HREF="Types.html">[Previous Page]</A></TD>
<TD><A HREF="index.html">[First Page]</A></TD>
<TD><A HREF="Dictionary.html">[Dictionary]</A></TD>
<TD><A HREF="mailto:walton@oclc.org">[Email Author]</A></TD>
<TD><A HREF="Support.html">[Next Page]</A></TD>
</TR>
</TABLE></CENTER>
</BODY>
</HTML>