Table of Contents
Concurrency support is build right into the central interface of
Glazed Lists, EventList. This may seem like mixing
unrelated concerns, but the advantages are worth it:
Populate your user interface components from a background thread
without having to use
SwingUtilities.invokeLater()
You can rely on explicit locking policies - you have to worry that you're calling synchronize on the wrong object!
Models like EventTableModel can queue updates to the Swing event dispatch thread when the source of the change is a different thread.
Filtering and sorting can be performed in the background
If your EventLists are used by only one
thread, you don't need to worry about locking.
Every EventList has a method
getReadWriteLock() that should be used for
threadsafe access. Read/Write locks are designed to allow access by
multiple readers or a single writer. The locks in Glazed Lists are
reentrant which allows you to
lock() multiple times before you
unlock().
To read from an EventList that is shared
with another thread:
EventList myList = ... myList.getReadWriteLock().readLock().lock(); try { // perform read operations like myList.size() and myList.get() } finally { myList.getReadWriteLock().readLock().unlock(); }
To write to a shared EventList:
EventList myList = ... myList.getReadWriteLock().writeLock().lock(); try { // perform write operations like myList.set() and myList.clear() } finally { myList.getReadWriteLock().writeLock().unlock(); }