From owner-freebsd-hackers@freebsd.org Mon Jul 13 16:31:17 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B5F86368F26 for ; Mon, 13 Jul 2020 16:31:17 +0000 (UTC) (envelope-from stephen.wall@redcom.com) Received: from smtp1.redcom.com (smtp1.redcom.com [192.86.3.143]) by mx1.freebsd.org (Postfix) with ESMTP id 4B58Kc6qrfz4991 for ; Mon, 13 Jul 2020 16:31:16 +0000 (UTC) (envelope-from stephen.wall@redcom.com) Received: from localhost (localhost [127.0.0.1]) by smtp1.redcom.com (Postfix) with ESMTP id 4888AA1C7 for ; Mon, 13 Jul 2020 12:31:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at redcom.com Received: from smtp1.redcom.com ([127.0.0.1]) by localhost (smtp1.redcom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR6RaYkfjvaA for ; Mon, 13 Jul 2020 12:31:10 -0400 (EDT) Received: from pie.redcom.com (pie [192.168.33.15]) by smtp1.redcom.com (Postfix) with ESMTP id 66B3FA1B5 for ; Mon, 13 Jul 2020 12:31:10 -0400 (EDT) Received: from exch-03.redcom.com (exch-03.redcom.com [192.168.32.32]) by pie.redcom.com (8.11.7p1+Sun/8.10.2) with ESMTP id 06DGVAl02590 for ; Mon, 13 Jul 2020 12:31:10 -0400 (EDT) Received: from exch-03.redcom.com (fd00::8549:68c0:3d5f:ee62) by exch-03.redcom.com (fd00::8549:68c0:3d5f:ee62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.330.5; Mon, 13 Jul 2020 12:31:10 -0400 Received: from exch-03.redcom.com ([fe80::a442:ce34:c9c8:268f]) by exch-03.redcom.com ([fe80::a442:ce34:c9c8:268f%3]) with mapi id 15.02.0330.010; Mon, 13 Jul 2020 12:31:10 -0400 From: "Wall, Stephen" To: "freebsd-hackers@freebsd.org" Subject: Re: mutex locking on file descriptors? Thread-Topic: mutex locking on file descriptors? Thread-Index: AQHWWRoXEPt2d/knTkKX89CPrcZPAakF2AAA///Ls9E= Date: Mon, 13 Jul 2020 16:31:09 +0000 Message-ID: <4bc963c9dd944c74a7d2419c3e3d2bcf@redcom.com> References: <0ae4590637e54a479228b38a823535a8@redcom.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.224.136] MIME-Version: 1.0 X-Rspamd-Queue-Id: 4B58Kc6qrfz4991 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of stephen.wall@redcom.com designates 192.86.3.143 as permitted sender) smtp.mailfrom=stephen.wall@redcom.com X-Spamd-Result: default: False [-0.54 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:192.86.3.143/32]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[redcom.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.53)[-0.530]; NEURAL_HAM_MEDIUM(-0.71)[-0.706]; NEURAL_HAM_SHORT(-0.10)[-0.103]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:46679, ipnet:192.86.3.0/24, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_COUNT_SEVEN(0.00)[7] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 16:31:17 -0000 > 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 ________________________________