[DotGNU]RE: PNet monitors

[Russell Stuart]

On Tue, 2004-04-27 at 19:39, Thong (Tum) Nguyen wrote:
> I think it's the opposite.  PNET remains as portable as ever -- it will
> still fall back to global locks on unsupported platforms and use more
> advanced (fast) features on support platforms.  This isn't much different to
> any other part of pnet.  A good example is how Rhys has written all the wait
> handle, mutex, thread-join and monitor support using pure C and one type of
> OS-supplied synchronization object (mutexes).

Yes, perhaps it will happen.  In the mean time, why not speed up the
implementation as it stands?  It will have the nice side effect of
speeding up all platforms - not just those somebody finds the time to
write specialised code for.

> > 
> > As I said in an earlier post, if don't free the monitors you
> > can get away with one global lock - when the monitor is first
> > attached to the object.  As most monitor objects are long
> > lived this generally has little performance impact - even if
> > you use pthreads.
> 
> That is true but this will mean that you need a way to free the monitor when
> the object gets collected.  You can do this by allocating the monitor on the
> GC-ed heap.  The only problem then is that you won't be able to allocate
> primitive arrays using GCAllocAtomic.  This means that large (large!) arrays
> of primitives will have to be unnecessarily scanned by the GC.  Another way
> is to attach finalizers to each and every object.  This has side-effects as
> well.
>  
> I don't think it's really possible to know which would be "better" without
> some real world benchmarks -- I think both techniques work well in different
> situations.  I originally did "just" allocate monitors on the GC heap (it
> was HEAPS easier) and that might be something that needs to be explored
> again.  At the time I figured using the double-check algorithm would pay off
> in the long run.  There's obviously a lot of optimisation that can be done
> but getting it to work is of course the number one priority.

Well, right now the situation we have is:
  - the code is complex, and as a consequence hard to understand,
  - it reportedly runs slowly, or at least so people say on IRC - I
    admit that might be just idle gossip,
  - right now it doesn't work.

I do agree that current the code is probably the fastest implementation
possible - no global blocks at all with the right machine specific
support.  Can't we come up with something that combines the two - that
uses the double check algorithm on machines that can support it, but on
machines that don't revert to the GC based algorithm?

The GCAllocAtomic problem looks solvable - even if we just make it a
special case.

In the mean time, how shall we proceed wrt the source?  Do you need it? 
Do you want me to just sent it to you?  Do you want to organise to get
the CE Machine talking to you at some later stage?