Re: Posix Semaphores in -CURRENT

[Joe Kelsey]

Terry Lambert wrote:

Joe Kelsey wrote:

I have been looking at the implementation of POSIX semaphores in
-CURRENT.  I noticed that there are several missing pieces, specifically
the man pages and the removal of uthread_sem.c from libc_r.

I suppose the man pages are not critical, but it seems silly to keep
uthread_sem.c in libc_r if there is a completely new kernel-based
implementation of the sem_* routines in -CURRENT.

First, realize that there is no such kernel implementation, in
the non-KSE case, and that the default in 5.0 is going to be
non-KSE (which will wait until at least 5.1).

I am not interested in threading. Named POSIX semaphores are inter-*process* synchronization more than they are inter-*thread* synchronization. I do not care about unnamed semaphores.

Second, realize that even if there were a shiny, happy kernel
implementation, it would be a bad idea to use it directly from
a threaded program.  This is because, even in the KSE world,
the thread scheduler is a hybrid, and it's possible to have a
multiplicity of threads in user space backed by a single kernel
context.  When this happens, crossing the user/kernel boundary
does nothing for you... except to make your program run slower.

Did I say anything about threads? Why would named posix semaphores depend on threads?

There are some other things about uipc_sem.c that seem unnecessarily
restrictive.  For one thing, it *requires* named semaphores to begin
with a '/' but not contain embedded '/'.  This seems like a severe
portabliity issue as TRU64 (at least) allows arbitrary pathnames as
sempahores, probably storing some sort of marker in the directories (I
get this only from examining the TRU64 online manual pages at
http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/HTML/APS33DTE_html/DOCU_010.HTM

I guess the question to ask at this point is whether it's talking
about disallowing embedding a '/' in a component, or disallowing
it as a component seperator.  I think you will find that it's the
former.

So, is there some mechanism I am missing? Is there a layer between the application calling sem_open and the kernel receiving the parameters that strips it down to the last component? If there is a higher level involved here, why is the low-level ksem_create function worrying about embedded '/' characters?

 There seems to be some broad interpretation of the POSIX semantice in
TRU64 to allow for negative semaphore values, one of their questionable
choices, although their example code is instructive).  Since the
semaphore names are merely stored in kernel structures, what difference
does it make if they contain embedded '/' characters or not?  And why
not allow names without leading '/'?  I don't think that there is any
wording in POSIX preventing this.

In general, an application should not assume interpretation of
standards.  If a standard is written such that it can be interpreted
in more than one way, then the application writer should assume that
some OS vendor has interpreted it in every possible way, and should
not depend on behaviour that requires a single interpretation to be
implemented by everyone.  Sucks, I know, but the only way around it
is to write your POSIX congressman.  In general, I think these types
of ambiguities arise *intentionally*: the standard is written so
that existing implementations already comply with it, so that vendors
don't have to change things, and can still claim compliance.

Yes, I realize this, but it seems that from my cursory inspection of uipc_sem.c that the check for embedded '/' characters is unnecessary and much too restrictive according to the posix standard. The standard only talks about whether or not the semaphore name begins with '/' and has nothing to say about embedded slashes except that the name must conform to filename requirements. It seems to me that either you take the TRU64 approach and place a marker in the file system (special directory entry?) or you allow all strings, only looking at the first character and not caring about anything else, except for whatever maximum pathname requirements you choose to impose.

Maybe I am missing something in the system call semantics?

/Joe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message