Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
But then I wonder
a) why xnregistry_fetch uses nklock at all (even for totally uncritical
XNOBJECT_SELF!)
registry_validate() returns a pointer we want to dereference; we'd better
keep
this unpreemptable, although it's
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
But then I wonder
a) why xnregistry_fetch uses nklock at all (even for totally uncritical
XNOBJECT_SELF!)
registry_validate() returns a pointer we want to
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
But then I wonder
a) why xnregistry_fetch uses nklock at all (even for totally uncritical
XNOBJECT_SELF!)
registry_validate() returns a pointer we want to dereference; we'd better
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
But then I wonder
a) why xnregistry_fetch uses nklock at all (even for totally uncritical
XNOBJECT_SELF!)
registry_validate() returns a pointer
Jan Kiszka wrote:
BTW, I'm also preparing a patch to overcome hash chain registrations for
anonymous (handle-only) objects as I need more of them (one for each
thread) for fast mutexes - to avoid fiddling with kernel pointers in
userland.
Ok. You will have a problem mangling a registry handle
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
BTW, I'm also preparing a patch to overcome hash chain registrations for
anonymous (handle-only) objects as I need more of them (one for each
thread) for fast mutexes - to avoid fiddling with kernel
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
BTW, I'm also preparing a patch to overcome hash chain registrations for
anonymous (handle-only) objects as I need more of them (one for each
thread) for fast mutexes - to
Jan Kiszka wrote:
OK, this all sounds like fast-lock awareness would have to be taught
to xnsynch first. But that would also open the chance to teach it
that handles are stored inside the lock word, no pointers.
That could be done too... But that would be really a critical change,
with updates
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
BTW, I'm also preparing a patch to overcome hash chain registrations for
anonymous (handle-only) objects as I need more of them (one for each
thread) for fast mutexes - to avoid fiddling with kernel pointers in
userland.
Ok. You will have a
Hi,
trying to select a sane kernel-side looking scheme for fast native
mutexes, I had a closer look at the registry usage in that skin (and
many others). The typical pattern is
object = xnregistry_fetch(handle);
perform_operation(object);
There is no lock around those two, both services do
Philippe Gerum wrote:
Jan Kiszka wrote:
But then I wonder
a) why xnregistry_fetch uses nklock at all (even for totally uncritical
XNOBJECT_SELF!)
registry_validate() returns a pointer we want to dereference; we'd better keep
this unpreemptable, although it's useless for the
Jan Kiszka wrote:
Hi,
trying to select a sane kernel-side looking scheme for fast native
mutexes, I had a closer look at the registry usage in that skin (and
many others). The typical pattern is
object = xnregistry_fetch(handle);
perform_operation(object);
There is no lock around
12 matches
Mail list logo
