[concurrency-interest] tsc register
davidcholmes at aapt.net.au
Fri Jan 13 16:24:23 EST 2012
Exactly. The TSC is not part of thread-state. There is no saving and
restoring. Plus if you did that it would no longer be a global counter.
From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Vitaly
Sent: Saturday, 14 January 2012 1:22 AM
To: David M. Lloyd
Cc: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] tsc register
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
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
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().
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest