From owner-freebsd-threads@FreeBSD.ORG Wed Apr 14 10:35:00 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9019416A4CE for ; Wed, 14 Apr 2004 10:35:00 -0700 (PDT) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 194C143D31 for ; Wed, 14 Apr 2004 10:35:00 -0700 (PDT) (envelope-from kirma@cs.hut.fi) Received: from kirma (helo=localhost) by hutcs.cs.hut.fi with local-esmtp (Exim 4.30) id 1BDoHq-0003ve-JZ for freebsd-threads@freebsd.org; Wed, 14 Apr 2004 20:34:58 +0300 Date: Wed, 14 Apr 2004 20:34:58 +0300 (EEST) From: Jari Kirma To: freebsd-threads@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Co-operative process yield/handoff syscall? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2004 17:35:00 -0000 I have been considering implementing concurrent queues between processes or between kernel driver and process(es) while attempting to removing unnecessary system calls and context switches in general. There are several good algorithms for this, FreeBSD has machine/atomic.h which provides nice atomic operations for both kernel and userland (which supposedly don't work nicely with MP Itanium without some help from kernel side, though). After reading some papers on the subject, I read one [1] which states that sched_yield that doesn't necessarily yield CPU to other runnable process if one exists can cause considerable performance hit on these algorithms. Quick look at FreeBSD kernel suggested me that sched_yield really yields CPU only if there's higher-priority process runnable. Is there any good way to emulate the co-operative "handoff" system call suggested on the paper? Primary feature of such a system call would be to avoid returning to the same process after sched_yield if any other runnable processes exist. I suppose inside a multithreaded process, pthread_yield performs what's expected in this case. [1] E. Unrau and O. Krieger, "Efficient Sleep/Wake-up Protocols for User-Level IPC", -kirma