From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48B4029A.4070103@domain.hid> Date: Tue, 26 Aug 2008 15:18:18 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <48B313B5.9050308@domain.hid> <48B32E0C.7000105@domain.hid> <48B33926.9060808@domain.hid> <48B3B999.6000707@domain.hid> <48B3BE60.4020709@domain.hid> <48B3C1B3.2050404@domain.hid> <48B3C443.9000704@domain.hid> <48B3FBBE.4050204@domain.hid> <48B40037.1030708@domain.hid> <48B4017A.906@domain.hid> In-Reply-To: <48B4017A.906@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] xnregistry_fetch & friends 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 Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: >>>> BTW, I'm also preparing a patch to overcome hash chain registrations for >>>> anonymous (handle-only) objects as I need more of them (one for each >>>> thread) for fast mutexes - to avoid fiddling with kernel pointers in >>>> userland. >>> Ok. You will have a problem mangling a registry handle with the claimed >>> bit. Or maybe we can assume that the bit 31 is not used or something ? >> That's precisely my plan, use the highest bit (2^32 registry slots are >> fairly unlikely even on 64 bit). >> >>> And by the way, I had an idea of removing the duplication of the owner >>> field between an xnsynch and a mutex object, this would allow saving a >>> syscall when a situation of mutex stealing happened. Using a handle >>> would prevent this. But I am not so sure it is a good idea now (namely >>> because it would move some compare-and-swap the owner logic to the >>> xnsynch API). >> How could you save one of the two syscalls on lock stealing? By >> introducing another bit in the fast lock word that indicates something >> like XNWAKEN? On first sight, this shouldn't require moving everything >> into xnsynch (though generic fast locks were not that bad...) nor >> interfere with handle-based lock words. > > The problem is that when the thread that did the stealing unlocks the > mutex, xnsynch_wakeup_one_sleeper must be called to set the xnsynch > owner to NULL, so that the robbed thread will succeed in getting the > xnsynch. But for xnsynch_wakeup_one_sleeper to be called, we must issue > the syscall. If the owner was shared between the mutex and the xnsynch, > the owner could be set to NULL by the mutex unlock from user-space. That is what the "sleepers" field in the pse51_mutex_t structure is for. -- Gilles.