cvs commit: src/sys/kern kern_proc.c

[Bosko Milekic]

Nate Lawson wrote:
>The only potential remaining problem is if another thread can increment
>the refcount after the unlock and i == 0 comparison but before
>"free(foo)".  In this case, you'll free an object that is still in use.
>It's safe to hold locks across free(), that's how I handle this case.
>
>-Nate

  This is not true if the object 'foo' cannot gain a reference unless
  an existing referrer passes it its own reference, which would make
  sense.

  If there is a way for a reference to 'foo' to be acquired without
  a reference to it already being held, then that code needs to be
  fixed and wherever the other reference to 'foo' is needs to ensure
  to properly increment the reference count.

  In other words, if you see that the count has hit zero in the GOOD
  code, then you know you're the last guy to have decremented the
  reference count and the only guy left referring to the object, so
  in theory, you should be the only thing allowed to GRANT an additional
  reference to 'foo'.

  Know what I mean?

  In other words, the GOOD code should be correct.

  -Bosko