From owner-freebsd-hackers Wed Feb 25 16:25:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA06993 for freebsd-hackers-outgoing; Wed, 25 Feb 1998 16:25:00 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fang.cs.sunyit.edu (root@fang.cs.sunyit.edu [192.52.220.66]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA06962 for ; Wed, 25 Feb 1998 16:24:43 -0800 (PST) (envelope-from perlsta@cs.sunyit.edu) Received: from win95.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by fang.cs.sunyit.edu (8.8.5/8.7.3) with SMTP id UAA08184; Wed, 25 Feb 1998 20:10:37 GMT Message-ID: <02f901bd424a$33dd5bc0$0600a8c0@win95.local.sunyit.edu> From: "Alfred Perlstein" To: "Terry Lambert" Cc: , Subject: Re: so how goes java? Date: Wed, 25 Feb 1998 19:05:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> >They are not pre-emptive. >> >> (figures since until recently the SUN version was also co-operative) >> one of my first things (besides fixing this problem) is to look into native >> threads, co-operative multitasking is an oxymoron. >> i also plan on having several snapshots of 3.0 compiled versions of the >> port. i'll inform the porting team when my NDA is all set and good. > >Do not confuse call conversion threading with Yield-based threading. > >Though call conversion threading is non-preemptive, one thread will >not be blocked simply because another thread has made a blocking >call. This is the point of call conversion. > >Kernel threading buys you SMP scalability (assuming there is ever >code changes checked in to ensure thread-CPU affinity), and a much >higher context switch overhead. ummm I think you just caused my brain to hemorrhage... :) but let me try to rephrase that just to make sure i understand. if we have 2 threads busy looping, for instance just printing "i'm thread A" and "i'm thread B", whichever thread starts first will not allow the other thread to execute, correct? however if one thread tries to do a disk access or something that could possibly block like a socket operation, the other thread will be allowed to start executing? ok, so what do I need to do to get a situation where the threads would alternate printing "i'm thread A" and "i'm thread B" when they are just busy looping? i think i understand that what you are refering to as kernel threads would work, however you also say they have a heavy overhead? are there any alternatives? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message