Re: threading of FileSet (was: Q. aboutMutableFileSet)
Jesse Glick <[email protected]> Fri, 20 Jun 2003 15:58:50 -0400
| Newsgroups | gmane.comp.java.netbeans.modules.projects.devel |
|---|---|
| Organization | Sun Microsystems / NetBeans |
| Message-ID | <[email protected]> |
Svatopluk Dedic wrote:
>> FS.runAtomic {
>> synchronized(xyz) {
>> FS.modify_and_fire_events();
>> }
>> }
>
> Please look at Mutex class and its evolution - first there were only
> methods with Runnables - but because of its frequent use (and many inner
> anonymous classes created), paired enter/exit methods were added later.
> It's not so safe for the API caller, but it is more effective for IDE's
> footprint (and execution time, too ;))
I would *not* recommend using Mutex.Privileged for new APIs. While it is
convenient, it also limits the kind of Mutex implementation to the
current general read-write lock. While I am still investigating the
details of how threading could work across NetBeans generally, one of
the most promising directions is something similar to Mutex which would
not support the equivalent of M.P - i.e. the lock really needs to be
given a complete runnable because it cannot process a single entry or
exit call on its own. Introducing M.P into the API prevents you from
using an important class of threading & locking designs later on.
Re. passing a Mutex to the FileSet constructor - perhaps keep it simple,
and just define one public static final Mutex MUTEX to be used with
*any* fileset. Simple and should work. You can just fire changes
synchronously with no special tricks. A Mutex rewrite I am working on in
a branch will let you temporarily switch the mutex into read-only mode
inside a write lock, mainly to enforce immutability while firing
changes, but using this call can be added to code later on.
Actually I am looking at more general designs (not specific to projects)
which would use a single lock for most kinds of internal data structure
manipulation in NB, so I would recommend keeping it as simple as
possible for now - if you don't have a particular reason to believe that
manipulation of these data structures will require some bizarre thread
wizardry, don't support it.
See discussion of Registry API on nbdev for comparison. I hope to come
up with a concrete proposal and guidelines and prototype sometime
soonish - in the meantime it is probably better to avoid writing any
more than the most trivial Mutex-based locking code.
-Jesse
--
Jesse Glick <mailto:[email protected]> x22801
NetBeans, Open APIs <http://www.netbeans.org/>