[tesla-dev] turnstiles block issue

[Li, Aubrey]

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