Date: Sat, 15 Jun 2002 20:45:19 -0700 From: Jeffrey Hsu <hsu@FreeBSD.org> To: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> Cc: jhb@FreeBSD.org, smp@freebsd.org, yangjihui@yahoo.com Subject: Re: Sharing a single mutex between a socket and its PCB Message-ID: <0GXS004W453AEO@mta5.snfc21.pbi.net> In-Reply-To: Message from Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> "of Sun, 16 Jun 2002 00:44:51 %2B0900." <200206151545.g5FFipAY006726@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> writes: > As some socket operations (eg sosend(), soreceive(), ...) modify both > a socket and its PCB at once, both of them should be locked by a > single mutex. Since hsu has already locked down struct inpcb, I would > like to protect a socket by the mutex of the PCB. > In order for the socket subsystem to lock and unlock opaquely, two new > usrreq methods will be added: > - pru_lock() locks the PCB of a socket. > - pru_unlock() unlocks the PCB of a socket. > If the PCB has its own mutex, those methods simply lock and unlock the > mutex. Otherwise, those methods lock and unlock the Giant lock. This > is so that we can push down Giant for the socket subsystem later. > Comments? Let's stick with the BSD/OS design, which is to have a separate socket buffer lock. It's better for concurrency this way. (BSD/OS also shows there's no need to have a separate socket lock. The socket buffer lock doubles as a socket lock.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0GXS004W453AEO>