The "decision", as I understand it, is how to interpret the spec.
Reasons to have another (not as "decided") interpretation: Because ThreadMXBean returns monitoring information it could be obsolete and so incorrect just after the obtaining. It gives an impression that bean can always return slightly incorrect information, for example in cases when strict value obtaining leads to possible performance degradation (adding synchronization to alive_thread_count decrement). Spec also supports such interpretation, because has statements like: "This method is designed ... not for synchronization control" or "Some threads included in the returned array may have been terminated when this method returns." Thanks, Andrey On 3/29/07, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 3/28/07, Andrey Yakushev <[EMAIL PROTECTED]> wrote: > > Similar problem was discussed here, see > > http://mail-archives.apache.org/mod_mbox/harmony-dev/200701.mbox/[EMAIL PROTECTED] > . > > As I remember, the decision was to have strict value instead of > approximation. So we have to synchronize alive_thread_count decrement > and other similar places as Weldon correctly noted. wait. I am confused by "decision". Is this a issue of following the spec for ThreadMXBean? Is this an issue of interpreting the ThreadMXBean spec to say "accurate"? Or am I missing the point and this is something entirely different. Thanks, > Andrey > > > On 3/28/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > > Weldon Washburn wrote: > > > Maybe I am misunderstanding the code. It looks like > > > "alive_thread_count--;" > > > could be executed concurrently by multiple threads and consequently > end up > > > with an incorrect value. Is it OK to have an approximate value? > > > > This variable is not used by JVMTI code, JVMTI doesn't deal with > > statistics. The code was added at revision 513013 from HARMONY-2059 and > > is an implementation of j.l.management.ThreadMXBean native part. > > > > Since this is just statistics, I think it may have an approximate value. > > > > -- > > Gregory > > > > > -- Weldon Washburn
