From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19647 invoked by alias); 21 May 2005 08:30:01 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 19511 invoked from network); 21 May 2005 08:29:50 -0000 Received: from unknown (HELO asav1.lyse.net) (213.167.96.68) by sourceware.org with SMTP; 21 May 2005 08:29:50 -0000 Received: from asav1.lyse.net (asav1.lyse.net [127.0.0.1]) by localhost.lyse.net (Postfix) with ESMTP id F1F999005F for ; Sat, 21 May 2005 10:25:24 +0200 (CEST) Received: from mail1.lyse.net (unknown [192.168.42.2])by asav1.lyse.net (Postfix) with ESMTP id E08859002Bfor ; Sat, 21 May 2005 10:25:24 +0200 (CEST) Received: from [84.234.138.230] (helo=[192.168.0.193])by mail1.lyse.net with smtp (Exim 4.34)id 1DZPLe-0002fY-1Wfor ecos-discuss@sources.redhat.com; Sat, 21 May 2005 10:28:42 +0200 From: =?ISO-8859-1?Q?=D8yvind?= Harboe To: ecos-discuss@sources.redhat.com Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 23 May 2005 09:13:00 -0000 Message-Id: <1116664216.28556.45.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-imss-version: 2.025 X-imss-result: Passed X-imss-scores: Clean:8.02178 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.1500 0.1500) Subject: [ECOS] Lightweight C++ multithreaded exceptions X-SW-Source: 2005-05/txt/msg00286.txt.bz2 One approach to supporting multithreaded exceptions that seem to work quite well in my experience is to use the single threaded GCC toolchain, but to make the the global variable in C++ exceptions, fc_static, per thread. By 'per thread' I mean that just like a generic CPU register, this global resource is part of the thread state. The easiest way of doing this that came to mind, was to add code to the eCos thread switching to save/restore the global variable on each thread switch. This requires reusing a field in the thread class or adding a new one. It was also suggested to make this support configureable via CDL as it adds a *very* slight overhead to thread switching. http://sources.redhat.com/ml/ecos-patches/2003-11/msg00047.html However, it requires a patch to GCC to make fc_static visible (it is currently declared static), which requires either get/set fn's or changing the name to avoid polluting the global namespace, e.g. _fc_static should do.=20 Advantages: - very easy to do. 2 lines of code, 30 lines of fluff(#if'defs', etc.) 50 lines of documentation :-) - GCC patch is simply changing: static void *fc_static; =3D> void *_fc_static; - no need to distinguish between single threaded or multithreaded toolchains - no need for multilib - very efficient implementation - no need for pthreads - trivial change to eCos - should work for all forseeable future Disadvantages: - requires a patch to GCC. --=20 =D8yvind Harboe http://www.zylin.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss