You hit the nail on its head! Thank you so much that detailed answer which clarified things a lot.
The confusion I have is during LL we never check if lock is already taken for that address or am I missing that part? As you correctly mentioned, the lock must be free to begin with. ~ Anusha ==================================================================================================================================== The SC (2) failing after (1) should force the program to loop trying properly execute a LL/SC pair. Assuming (1) and (2) properly execute, the value of the lock will be set to taken. This would force your other thread to continuously loop on its LL until it saw the lock was free. I think your confusion might be coming from understanding that "properly grabbing a lock" involves 2 things. 1) the LL/SC pair executes without failing and 2) The lock was free to begin with (the value stored at the locks address in memory). If the LL/SC pair fail, we will never store a value in memory that says "this lock is taken". In your originally posted code... The branch @ line 3 was conditional on the lock being free to begin with. And the branch @ line 5 was conditional on the SC succeeding (basically no one took the lock in between the time we realized it was free). On Tue, Nov 20, 2012 at 3:24 PM, Anusha <anu.j...@gmail.com> wrote: > > > (1)-- LL by thread 2. lock = 2 (load linked) > ===============> any > operation here to that address will cause SC to fail due to isLocked logic > in SC > (2) --SC by thread 2 . lock = -1 (store conditional) > ^ > | (3) -- LL by thread 3. lock = 3 > | (4) -- SC by thread 3 . lock = > -1 > | > | CR } at this point both thread 2 and 3 are in CR. > | > V > (5) -ST . lock =-1 > > Is the above scenario possible? I am not able to find logic that will > prevent thread 3 from executing LL and SC. > > ~ Anusha
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
