From owner-freebsd-hackers Wed Feb 6 18:41:56 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 03C8637B41E for ; Wed, 6 Feb 2002 18:41:50 -0800 (PST) Received: from pool0137.cvx22-bradley.dialup.earthlink.net ([209.179.198.137] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16YeVP-0005da-00; Wed, 06 Feb 2002 18:41:47 -0800 Message-ID: <3C61E966.338CA0@mindspring.com> Date: Wed, 06 Feb 2002 18:41:42 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Umesh Krishnaswamy Cc: freebsd-hackers@freebsd.org Subject: Re: porting multithreaded app from linux to FreeBSD References: <20020206143846.Q17649@juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Umesh Krishnaswamy wrote: > Are there any gotchas about porting over from Linux a multi-threaded > application? FreeBSD version that I am using is 4.2. FreeBSD 4.2 uses a user space threading model. Linux threads are supported through the use of a GPL'ed kernel module and library, so you will need to consider licensing issues if you go that route. If you just use pthreads, Linux programmers often make some assumptions about thread scheduling which are not correct in the case of a user space threads scheduler, even though that is perfectly legal. For example, the Java GIF renderer in Netscape was not thread reentrant, because it assumed that the active thread would be restarted, instead of another thread, should the entire process be involuntarily context switched, and then rescheduled to run. This led to problems with Java applications causing Netscape to crash on FreeBSD and Macintosh, when they worked fine on Windows, Linux, and other OSs using the Windows assumptions. Another program that is commonly written is an infinite "printf" loop, with another infinite loop with a "sleep" for one secong in a seperate thread. This assumes that the preemption of one thread vs. another will occur at the kernel quantum distribution level, and thus the resulting program will crank out a bunch of the firt printf's (e.g. "x"), and the second will crank out its printf once a second (e.g. "o"). This fails, because the first thread is never context switched away by the user thread scheduler, which does not do quantum distribution (round-robin or otherwise). This is all beside the fact that a buzz loop is incredibly bad programming practice under any circumstances, because it will take all available CPU, and drop in priority as a result of being such a pig. If you don't make scheduling assumptions, and you don't write infinite loops and expect context switches, you should not have problems. If you want more examples, check the mailing list archives for problem reports involving threads, or the PR database, including resolved problem reports about threads, where the resolution was "programmer error" or otherwise "won't fix". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message