cvs commit: src/sys/kern uipc_sem.c

[Robert Watson]

On Sat, 26 Feb 2005, Antoine Brodin wrote:

> Robert Watson <rwatson at FreeBSD.org> wrote:
> > On Fri, 25 Feb 2005, Antoine Brodin wrote:
> > 
> > > I think you forgot to increment i, maybe you should replace
> > > sem_array[i] = ks; by sem_array[i++] = ks; ?  And the " + 1" in the
> > > KASSERT looks bogus too ;). 
> > 
> > Antoine,
> > 
> > As usual, good eyes :-).  I tested the loop code, and then proceeded
> > to change other things, and neglected to run the test case afterwards.
> 
> By the way, I'm not sure a race with other threads in the parent process
> can happen during fork(): thread_single() is called at the beginning of
> fork1() if the parent process has had threads and thread_single_end() is
> called at the end.  Perhaps a thread guru can confirm this. 

I've broadened the CC to include threads@ because I'm not entirely sure of
the semantics of the single threading mechanism in kernel -- specifically,
how it behaves in the presence of 1:1 threads.

Just to provide a bit more context for those on the list -- uipc_sem.c
does some paperwork at fork() time so the parent and child processes both
have references to the same set of semaphores.  The way this is done right
now is that the thread in kernel calling fork takes a snapshot of the set
of semaphores, bumping their reference counts, then goes off and adds them
to the child which involves potentially sleeping memory allocation.  Under
the assumption that other threads in the parent might still be executing,
I address the issue through the snapshot and then assign the references
owned by the snapshop array to the child process as the memory allocation
takes place.  This adds some overhead, which would be nice to get rid of
-- if the snapshot is unnecessary.

So the question is -- will the parent process see any parallelism in
kernel during fork() for any of our threading model, or do we prevent
that?

Robert N M Watson