Date: Mon, 13 Jul 2020 16:31:09 +0000 From: "Wall, Stephen" <stephen.wall@redcom.com> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: mutex locking on file descriptors? Message-ID: <4bc963c9dd944c74a7d2419c3e3d2bcf@redcom.com> In-Reply-To: <e0a2b90c-fb7a-abf3-97e1-d4570144b375@grosbein.net> References: <0ae4590637e54a479228b38a823535a8@redcom.com>, <e0a2b90c-fb7a-abf3-97e1-d4570144b375@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> This heavily depends on exact "issues" you are try to avoid, amount of da= ta wrote or read, > used protocol and driver. > > In some cases, for some types of descriptors there is atomicy for small w= rites. > But in general you need some kind of locking. Else you may get unexpected= results, > f.e. some part of data read by one thread and another part by another thr= ead. OK, more details. The device driver is providing unfiltered access to a bu= lk endpoint on a Silicon Labs device, which speaks a protocol defined by SI= Labs supporting packets of up to 64 bytes in length. Most are much shorter= that that, 10-20 bytes. The device's datasheet doesn't state it, but in t= esting I've never seen one of these packets fragmented. I will have a thread that writes queries on a timed basis, and reads replie= s to those queries, as well as hardware-triggered messages, using kqueue to= receive notification that data is available. It will process the messages= and store relevant data in class variables for consumption as needed. Where I have a concern is that I'm also providing functions to bypass this = mechanism, and give consumers a way to send custom messages to the device, = which means a write can also happen outside the thread discussed above. I = thought that I needed a mutex to protect against a context switch happening= in the middle of one or the other of the accesses, until my co-worker's co= mments. This comment from usbdi.h seems to support that read and write a= re already protected: /* * Locking note for the following functions. All the * "usb_fifo_cmd_t" and "usb_fifo_filter_t" functions are called * locked. The others are called unlocked. */ I guess I will assume the mutex is needed, unless someone can definitively = say it's not. Thank you, Eugene. - Steve Wall ________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4bc963c9dd944c74a7d2419c3e3d2bcf>