Bill.Holler at Sun.COM wrote: > 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. >> > ^--- NOT > > Sorry, I meant to say accessing these registers does *not* halt the > processor. > > Bill
oh yeah, what I guess is right, :-) -Aubrey
