Thank you so much for your response. line 1 -- Try: LL R2, (R1) /-- read lock line 2 -- ORI R3, R2, 1 line 3 -- BEQ R3, R2, try line 4 -- SC R3, (R1) /-- acquire lock line 5 -- BEQ R3, 0, try /*---critical section---*/ line 6 -- SW R2, (R1) /-- release the lock
The part I am not very clear about is do lines 1-3 correspond to normal instructions in gem5?, line 4 to setting lock to context id (using LL implementation of gem5) and line 6 to SC implementation of gem5? ================================================================================================================================================= "It releases the lock using normal store" I think this might be where your confusion is coming from. This is not true, it does a store conditional not a normal store. The store conditional only stores if the context id is still set on the cacheline. This code is in (if ruby) src/mem/ruby/system/Sequencer.cc in Sequencer::handleLlsc(). So if an LL/SC from another thread overlaps, this guarantees that a thread's SC does not complete the store if the last load linked was issued by the same thread. On Mon, Nov 19, 2012 at 10:45 PM, Anusha <anu.j...@gmail.com> wrote: > I have a question regarding LL/SC implementation in gem5. > > For example, if thread 1 performs a LL operation, it sets locked flag to > context id. During SC operation, lock flag is cleared. > It releases the lock using normal store and lock flag is cleared during > any WB. > > If another thread (id 2) tries to perform a LL operation, while thread 1 > is in CR, it will set flag to its context id. > > The question I have is what will prevent thread 2 SC from succeeding > while thread 1 is in CR. I am unable to find a condition that checks if > another thread is executing CR. > > I would really appreciate if someone could clarify this for me. > > Thanks, > Anusha
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
