From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5842 invoked by alias); 29 Jul 2002 23:22:12 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 5811 invoked from network); 29 Jul 2002 23:22:11 -0000 Received: from unknown (HELO anchor-post-32.mail.demon.net) (194.217.242.90) by sources.redhat.com with SMTP; 29 Jul 2002 23:22:11 -0000 Received: from tymora.demon.co.uk ([158.152.73.141] helo=tymora.bartv.net) by anchor-post-32.mail.demon.net with esmtp (Exim 3.35 #1) id 17ZJq4-0007eG-0W; Tue, 30 Jul 2002 00:22:09 +0100 Received: from delenn.bartv.net (unknown [10.1.1.1]) by tymora.bartv.net (Postfix) with ESMTP id D61A967078; Mon, 29 Jul 2002 22:34:23 +0100 (BST) Received: by delenn.bartv.net (Postfix, from userid 372) id 92A6B6165C; Mon, 29 Jul 2002 22:34:16 +0100 (BST) From: Bart Veer To: george@stratalight.com Cc: ecos-discuss@sources.redhat.com In-reply-to: (george@stratalight.com) Reply-To: bartv@tymora.demon.co.uk References: Message-Id: <20020729213416.92A6B6165C@delenn.bartv.net> Date: Mon, 29 Jul 2002 16:22:00 -0000 Subject: Re: [ECOS] malloc/new in DSRs X-SW-Source: 2002-07/txt/msg00439.txt.bz2 >>>>> "George" == George Sosnowski writes: George> If malloc is configed to be threadsafe in ecos.ecc, then George> is it ok to use malloc/new/free/delete in DSRs? I assume George> it is, but want to make sure. The short answer is no: thread context is very different from DSR context, see the kernel documentation. The obvious way of implementing a thread-safe malloc() uses a mutex to protect the heap shared data, so any malloc() or free() calls need to lock the mutex and then unlock it again. A DSR is not allowed to call a mutex lock function. Consider what might happen if a DSR did try to call malloc(). Suppose some thread is in the middle of a malloc() call, and hence has the mutex locked. An interrupt now goes off, the ISR runs and requests a DSR invocation. Your DSR now calls malloc(), tries to lock the mutex, and discovers the mutex is already owned by a thread. So the DSR would need to wait until the thread had unlocked the mutex, but DSRs have absolute priority over threads so the thread cannot run again until the DSR has completed. Deadlock. Now for a longer answer: the current implementation of threadsafe malloc() does not always use a mutex to protect the heap. Instead it locks the scheduler. In this scenario it would actually be safe to call malloc() from a DSR because DSRs will not run if the scheduler is locked. However this is really a bug in the current malloc implementation, a left-over from the early days when the only allocator was the fixed block one, and may get fixed at any time. Therefore you should not rely on the current behaviour. There is an argument that for certain implementations of memory allocators, especially fixed block ones, it is legitimate to use a scheduler lock rather than a mutex: the implementation of mutex lock and unlock implicitly involves locking the scheduler; so for a sufficiently simple memory allocator, briefly locking the scheduler might actually be preferable to using a mutex. This needs further investigation. Bart -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss