[concurrency-interest] tsc register

Vitaly Davidovich vitalyd at gmail.com
Fri Jan 13 10:22:01 EST 2012


I don't think tsc is saved and restored as it's not associated with a user
or kernel context.  Its not like we save and restore wall clock time :).
On Jan 13, 2012 10:15 AM, "David M. Lloyd" <david.lloyd at redhat.com> wrote:

> On 01/12/2012 11:13 PM, David Holmes wrote:
>> Mohan Radhakrishnan writes:
>>> I meant that since this CR is recent even newer VM's could be affected
>> That CR has nothing to do with the TSC.
>>  ? I think if I were to set the thread affinity using JNI and
>>> continuosly run java threads then that is the test case. Am I right ?
>> If you bind a thread to a given core (using JNI) and that thread reads
>> the TSC then it should always be reading the same TSC. But remember there
>> are two issues with using the basic TSC: synchronization across processors
>> and stability of the frequency of updates. Thread affinity only addresses
>> one part.
> Synchronizing TSC across processors seems like a non-requirement from our
> perspective.  As long as the TSC value is saved and restored on context
> switch, each thread will see a monotonic increase, right?  And really
> that's about as much as you ought to expect out of nanoTime().
> --
> - DML
> ______________________________**_________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120113/464ebb2e/attachment.html>

More information about the Concurrency-interest mailing list