Hi Bill, Bill.Holler wrote:
> Li, Aubrey wrote: >> Dana.Myers wrote: >> >> >>> Li, Aubrey wrote: >>> >>>> Dana.Myers wrote: >>>> >>>> >>>>> Let's take a step back here and think about what we really >>>>> want to happen. >>>>> >>>>> Cx is controlled using P_BLK registers, which are a per-CPU >>>>> hardware resource; is it correct to assume that manipulation of >>>>> a P_BLK is always done on the corresponding CPU? Another way of >>>>> stating this - is it correct to assume that a P_BLK is never >>>>> manipulated by another CPU? >>>>> >>>> No, we are not talking about P_BLK, we are talking about BM_STS in >>>> PM1 Status Registers, which is not a per-CPU hardware resource, >>>> and BM_RLD as well. >>>> >>>> >>> Ah, well. Something seems wrong with a thread holding a machine >>> global lock on machine global resources on a CPU that's not >>> executing - while other CPUs may contend for that same lock. Help >>> me understand the use-case and why this isn't bad. >>> >> >> The problem is, currently we are using adaptive mutex for this >> global lock, and we are in idle thread. So one cpu hold this lock, >> and another cpu has to wait. We can keep spinning here, and we also >> can put this cpu's thread to sleep. Here, we are not spinning here, >> we are trying to put this thread to sleep. But, this is idle thread, >> it can't be put to sleep. >> > > To be clear: the BM_STS and PM1 status register access does > halt the CPU. The CPU does not halt holding the lock. > > Bill > Sorry I didn't catch your point. Reading PM1 status register will not halt the CPU. Typo? Thanks, -Aubrey
