https://issues.apache.org/bugzilla/show_bug.cgi?id=49778
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://issues.apache.org/bugzilla/show_bug.cgi?id=49778
--- Comment #5 from Daniel Luo 2010-08-20 08:05:04 EDT ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > >
> > > > Since the lock is dropped immediately after retrieving
> > > > the value, the value m
https://issues.apache.org/bugzilla/show_bug.cgi?id=49778
--- Comment #4 from Sebb 2010-08-19 19:39:28 EDT ---
(In reply to comment #3)
> (In reply to comment #2)
> >
> > > Since the lock is dropped immediately after retrieving
> > > the value, the value may change well before any decisions
> > >
https://issues.apache.org/bugzilla/show_bug.cgi?id=49778
--- Comment #3 from Chuck Caldarale 2010-08-19
19:11:53 EDT ---
(In reply to comment #2)
>
> > Since the lock is dropped immediately after retrieving
> > the value, the value may change well before any decisions
> > can be made based on t
https://issues.apache.org/bugzilla/show_bug.cgi?id=49778
--- Comment #2 from Sebb 2010-08-19 19:02:10 EDT ---
(In reply to comment #1)
> Such a change is utterly useless.
Not true.
The synchronisation block ensures that the value read by the thread is the
current value.
> Since the lock is
https://issues.apache.org/bugzilla/show_bug.cgi?id=49778
--- Comment #1 from Chuck Caldarale 2010-08-19
08:54:53 EDT ---
(In reply to comment #0)
> Proposed solution:
>
> public int getCount() {
> int ret = 0;
> synchronized (lock) {
> ret = current+1;
> }
> return ret;
> }
Such a
