Date: Wed, 06 Feb 2002 18:41:42 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Umesh Krishnaswamy <umesh@juniper.net> Cc: freebsd-hackers@freebsd.org Subject: Re: porting multithreaded app from linux to FreeBSD Message-ID: <3C61E966.338CA0@mindspring.com> References: <20020206143846.Q17649@juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C61E966.338CA0>