Semaphores, End of Shared Key Register Tables debate

[Jonathan Shapiro]

   In that case I suspect this feature (read-only Key Table slots) may
   cause more trouble than it's worth - an extra load and bit-test
   every time you write a key, at any rate. 

The extra six instructions there (worst case) don't bother me
especially.  Just forcing slot 0 to be void may really be a better
answer.  My concern is that not all key tables are key register
tables, and that it is quite possible for a key table to be
simultaneously one process's key table and another processes key
register table.  Given this, making slot 0 special as a concession to
messageing may be less desirable.

I still think it's worth considering.

   Or just don't directly support throwing keys away at all -

This has the effect of substantially increasing key register pressure,
so I'm very reluctant to do that.  I consider things tight for proper
UNIX emulation at 16 keys.

   Good example [multiple threads] but here's a reason it might not
   hold up completely as an argument for shared key tables.  Accesses
   to any shared resource must, in general, be synchronized somehow...

   In the KeyKOS "religion", as I understand it, the basic "standard"
   inter-thread synchronization mechanism is IPC.  

Actually, KeyKOS more or less always assumed that fast semaphores
would be implemented in shared memory.  On the few architectures that
do not provide such instructions, KeyKOS provided them as kernel
non-interrupted fast path traps.  I think the view, however, was that
the kernel had no need to be involved in implementing semaphores of
this kind, and basically I think that view is sound.

No reason why you should have inferred this from any of the discussion
to date.


I think the discussion about shared key register nodes has failed to
note something important, and has been consequently misfocused.  I
only realized this in responding to your thoughts here, and I
apologize for pursuing a wasteful line of debate for so long.

I'm going to attempt to lay the debate out very precisely, in the hope
of putting it to bed or focusing it.

There are two issues: 

  1) whether sharing a key register table has implications for
     correctness.
  2) whether shareing a key register table is advisable as a matter of
     taste, assuming it can be done correctly.

I believe that such sharing can be correct, according to the following
reasoning:

1) Domains need to share key tables for exactly the same reasons that
   they need to share segments.

2) Depending on application conventions and required semantics,
   correctness may require that the domains synchronize such sharing.

3) Such synchronization, if needed, can be implemented through IPC or
   through in-memory semaphores in a shared segment.

4) The fact that a key table happens to be in use as a key register
   table does not alter statements (2) or (3).  Key register tables
   really are not "special."

Therefore, whether a key table happens to be a key register table is
orthogonal to whether state sharing can be correctly implemented.

Unless I've missed something, the debate is now reduced to one of
taste.  I submit that this is a question of application convention,
and that we are ill-equipped to argue it from first principles.  Based
on the discussions we have had to date, I concur that shared key
register tables looks less desirable than I had thought.

Given that a set of processes wishes to share something close to 16
keys, and otherwise do not need more than 16 private keys, I can
envision no technical reason why the processes should NOT share the
shared table as a second key register table.  If you buy this, then we
are "arguing about the price."



Jonathan