On Wednesday 10 January 2007 10:03, Randall Stewart wrote: > Robert/All: > > Ok, here is the deal... I have looked in a bit > closer at this.. > > Here is what is happening... > > When a cookie arrives, we get a "create lock" on > the socket this prevents the user on the same > socket from creating a assoc at the same exact time. Can't you do a model like this: lock(); if (need to create pcb) { unlock(); create_pcb(); // can sleep w/o holding lock lock(); if (someone else created the pcb) free(pcb_I_just_created); } unlock(); This is used in several places in the kernel to handle concurrent object creation races. Speaking of the sx(9) man page there are two things to note: 1) There are already patches to make sx(9) locks just as efficient as mutexes in the common case (single atomic op), so that comment is likely irrelevant (and probably shouldn't have existed in the first place). 2) If you are already willing to sleep by calling hashinit() (which can sleep in malloc()), then blocking on a sx lock is already fine for the code where you are doing this. -- John BaldwinReceived on Wed Jan 10 2007 - 18:53:12 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:04 UTC