From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48F38E99.5020602@domain.hid> Date: Mon, 13 Oct 2008 20:08:25 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <48F33543.6070303@domain.hid> <48F3380B.6040503@domain.hid> <48F33AEC.9080608@domain.hid> <48F33C4F.4020001@domain.hid> <48F35A40.9040306@domain.hid> In-Reply-To: <48F35A40.9040306@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] Fast mutexes vs. automatic mode switch List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai-core Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> As we are already fighting hard to avoid new explicit mode-switch use >>> cases, rather get rid of old ones, I thought it would be better to keep >>> existing semantic across the fast mutex changes. >>> >>> Regarding those shared maps: they are per process, aren't they? But here >>> we need per thread memory. I'm currently thinking of a memory piece that >>> the caller of xeno_set_current provides (or some service that is called >>> together with the latter one, or some extended services - to keep APIs >>> clean). Then, on mode switches, the kernel will carefully >>> (xn_copy_to_user) update it. >> We can allocate a piece of memory on the shared heap, and attach it to a >> thread using a pthread_key. > > What would be the advantage of using a heap chunk over doing xn_copy_*? > I haven't looked into details yet but, in contrast to the mutex stuff, I > don't expect that we will have to access that data from within critical > regions. Well, it is a more general solution, which should allow to access many details in user-space. But I find it no real use right now. -- Gilles.