Date: Mon, 17 Jun 2002 18:04:33 +0900 From: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> To: Jeffrey Hsu <hsu@FreeBSD.org> Cc: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, jhb@FreeBSD.org, smp@FreeBSD.org, yangjihui@yahoo.com Subject: Re: Sharing a single mutex between a socket and its PCB Message-ID: <200206170904.g5H94X3i076651@rina.r.dl.itc.u-tokyo.ac.jp> In-Reply-To: <0GXS004W453AEO@mta5.snfc21.pbi.net> References: <tanimura@r.dl.itc.u-tokyo.ac.jp> <200206151545.g5FFipAY006726@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <0GXS004W453AEO@mta5.snfc21.pbi.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 15 Jun 2002 20:45:19 -0700, Jeffrey Hsu <hsu@FreeBSD.org> said: >> 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? hsu> Let's stick with the BSD/OS design, which is to have a separate socket buffer hsu> lock. It's better for concurrency this way. (BSD/OS also shows there's no hsu> need to have a separate socket lock. The socket buffer lock doubles as a hsu> socket lock.) It helps the lock order issue of a socket and PCB lock to export PCB's mutex. You never have to release a socket lock to acquire a PCB lock as BSD/OS does: tcp_usrreq(so) { sb = so->so_buf; SOCKBUF_UNLOCK(sb); /* XXX What if someone modified the socket? */ INP_LOCK(inp); SOCKBUF_LOCK(sb); tcp_do_usrreq(); INP_UNLOCK(inp); } Speaking of concurrency, it does not scale to run only one net swi thread on an MP machine. Maybe we can make a pool of net swi threads and run them in parallel. -- Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@FreeBSD.org> 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?200206170904.g5H94X3i076651>