From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by ozlabs.org (Postfix) with ESMTP id 10F7E67BA2 for ; Tue, 29 Aug 2006 23:37:57 +1000 (EST) Received: by wr-out-0506.google.com with SMTP id i20so536699wra for ; Tue, 29 Aug 2006 06:37:56 -0700 (PDT) Message-ID: Date: Tue, 29 Aug 2006 21:37:37 +0800 From: "Li Yang" Sender: linuxppcleo@gmail.com To: linuxppc-embedded@ozlabs.org Subject: RE: atomic operations in user space MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > This is exactly how it is supposed to work! That's why there is a loop > in the atomic increment - you check if you still had the reservation > after the transaction by checking the result from the stwcx, and if not, > retry. I surely know all the theories you mentioned clearly. But please do look at the case I gave. Correct me if I missed anything. Thanks All the lwarx and stwcx operate on the same address. > Task A Task B > lwarx // Get RESERVATION > ...... > lwarx > stwcx // RESERVATION cleared > > ..... > ..... > lwarx // Get RESERVATION again > stwcx //Note here: RESERVATION is valid, address is the same. So the result is commited, no retry for task A > ..... > stwcx //RESERVATION is cleared, retry atomic op for task B Please be noted that reservation is only identified by reservation bit and address operated on. So different lwarx's on the same address, may be considered as the same reservation.