> new Thread(
>
[quoted text clipped - 7 lines]
> opposed to a class that simply implements runnable which receives no
> warning?
The only reason I can think of why it might make sense to synchronize anything
here is if the run() method accesses a member variable of the enclosing class.
david m- - 05 Jan 2004 14:00 GMT
> > new Thread(
> >
[quoted text clipped - 10 lines]
> The only reason I can think of why it might make sense to synchronize anything
> here is if the run() method accesses a member variable of the enclosing class.
Not quite sure whether this small extract is complete enough to be
representative, but...
Wouldn't synchronized applied to run lock at the anonymous inner object
level, i.e. Runnable
And not at the outer object, i.e. Thread, level.
i.e. applying a lock to the inner object does not offer any multi thread
protection.
david m.
Michael Borgwardt - 05 Jan 2004 14:59 GMT
>>The only reason I can think of why it might make sense to synchronize anything
>>here is if the run() method accesses a member variable of the enclosing class.
[quoted text clipped - 6 lines]
> i.e. applying a lock to the inner object does not offer any multi thread
> protection.
True. just slapping "synchronized" into the method declaration would not suffice
(it rarely does); you'd have to use a synchronized(){} block with the right
monitor and granularity.
> new Thread(
>
[quoted text clipped - 5 lines]
>
> Why does jlint warn me that the 'run' method is not synchronized...
If you are using the Athro version of Jlint, then from the user manual, chapter
3, Bugs detected by Jlint:
3.1.9 Method name [sic] implementing 'Runnable' interface is not synchronized
Method run() of class implementing Runnable interface is not declared
as synchronized. As far as different threads can be started for the same
object implementing Runnable interface, method run can be executed
concurrently and is first candidate for synchronization.
Arguably Jlint could detect that the synthetic class that is used to implement
the "inner class" is only ever used in a context where there is no shared
access to any of its instances, but I suspect that the analysis required would
be more than a little involved.
> ... as
> opposed to a class that simply implements runnable which receives no
> warning?
But I have no guess why this case does not trigger the same warning. A bug
perhaps ?
I think this particular warning is of very questionable value anyway.
-- chris