Re: RFC: Lightweight synchronization mechanism for gnumach v2.0

[Samuel Thibault]

Hello,

Agustina Arzille, on Tue 29 Mar 2016 22:37:27 -0300, wrote:
> As for Linux, they too use a global hash table, but its size is determined
> by the number of CPUs (The actual size is 256 * NCPUS).

Ok. Doing the same is probably a good start.

> For shared gsync objects, I'm using vm_map_lookup to find out the
> vm object and offset. The problem is that said function expects the map
> to be unlocked

Really?

It starts with locking it, and finishes with unlocking it, and the lock
is recursive, so it's fine to take it several times.

> A simple workaround is
> to do valid_access_p *again* after vm_map_lookup returns (It should be
> faster since the vm hint should be set by then).

But there's still room between that call and the dereference. We really
need to have the map locked between the access check and the actual
dereference.

> >Thanks for your work!
> >
> >BTW, how is your copyright assignment going?
> 
> Slow. I sent the letter about 20 days ago, still no answer.

Don't hesitate to ping the people at FSF from times to times, to make
sure it's not stuck somewhere.

Samuel