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/>