Bill Holler 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. > OK - I'm less confused now - this matches my understanding of PM1 status :-).
But I'm still confused; does the CPU release the global hardware lock before halting?
