<AWT Dev> numAppContexts in AppContext modified in not-thread-safe way.

David Holmes David.Holmes at oracle.com
Thu Aug 18 16:05:05 PDT 2011

On 19/08/2011 8:02 AM, Clemens Eisserer wrote:
> Mario wrote:
>     It looks good to me, and I don't expect any issues after this patch.
>     The only thing is that you should check the settings for the editor, I
>     think you still use a mix of tabs and spaces :)
> Hmm, I should really check those eclipse settings ^^
>     Also,
>     public final static AppContext getAppContext()
>     Doesn't seem to be thread safe by nature, I don't know if this is part
>     of the issue you found, so maybe you should consider to synchronize
>     this as well.
> Could be I got this wrong ... but isn't the idea behind getAppContext() that
> it can be called  from any thread, and get the AppContext(if there is any) back?

Right. The appContext table is a synchronized map keyed on the current 
ThreadGroup. The first thread created in a ThreadGroup for a given 
AppContext will create the AppContext before any other threads can be 
created, hence this is thread-safe.

The change to use AtomicInteger seems okay - the main concern would be class 
initialization problems, but presumably that doesn't happen. Part of the 
missing picture here is how AppContexts get created and dispose()'d as it 
may be that the way AppContext is used you can't actually get concurrent 
modification of numAppContexts. But there's no way to discern that from the 
AppContext code so it would be safer to use the AtomicInteger.

David Holmes

> - Clemens

More information about the awt-dev mailing list