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 <[email protected]> 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 > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
