[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Samuel Thibault
Subject: Re: RFC: Lightweight synchronization mechanism for gnumach v2.0
Date: Thu, 31 Mar 2016 01:07:20 +0200
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)


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


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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]