From owner-freebsd-hackers Sun Jul 5 13:33:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA24250 for freebsd-hackers-outgoing; Sun, 5 Jul 1998 13:33:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tim.xenologics.com (tim.xenologics.com [194.77.5.24]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA24218 for ; Sun, 5 Jul 1998 13:33:42 -0700 (PDT) (envelope-from seggers@semyam.dinoco.de) Received: (from uucp@localhost) by tim.xenologics.com (8.8.5/8.8.8) with UUCP id WAA26526; Sun, 5 Jul 1998 22:05:14 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by semyam.dinoco.de (8.8.8/8.8.8) with ESMTP id WAA06547; Sun, 5 Jul 1998 22:02:56 +0200 (CEST) (envelope-from seggers@semyam.dinoco.de) Message-Id: <199807052002.WAA06547@semyam.dinoco.de> To: zhihuizhang Cc: hackers@FreeBSD.ORG, seggers@semyam.dinoco.de Subject: Re: Lock mechanism questions In-reply-to: Your message of "Sat, 04 Jul 1998 16:20:57 EDT." Date: Sun, 05 Jul 1998 22:02:55 +0200 From: Stefan Eggers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > By the way, I know spin lock is not suitable for interrupt routines that > access the same data structures. Can anyone give me a reason for this? Isn't that because of the problems you have when a higher priority interrupt occurs while serving a lower priority interrupt and both want to access the data structures? Then the lower priority one would have to get at least to the place where it frees the lock to allow the higher priority one to continue. But how does it achieve this? The higher priority interrupt gets serviced first. Deadlock. The same for an interrupt and a normal kernel function which both try to access the same spin lock protected data structure. Then a similar situation arises. For processes it works as the waiting process eventually has to give up the CPU. Then the process holding the lock can work further toward releasing it. That's how I understand this problem with what I know as spin lock. I might be wrong of course. Stefan. -- Stefan Eggers Lu4 yao2 zhi1 ma3 li4, Max-Slevogt-Str. 1 ri4 jiu3 jian4 ren2 xin1. 51109 Koeln Federal Republic of Germany To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message