From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9635 invoked by alias); 15 Sep 2009 11:12:02 -0000 Received: (qmail 9627 invoked by uid 22791); 15 Sep 2009 11:12:02 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from www.meduna.org (HELO meduna.org) (92.240.244.38) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Sep 2009 11:11:58 +0000 Received: from dial-78-141-95-31-orange.orange.sk ([78.141.95.31] helo=[192.168.130.27]) by meduna.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MnVwv-0000yb-6R for ecos-discuss@ecos.sourceware.org; Tue, 15 Sep 2009 13:11:55 +0200 Message-ID: <4AAF766C.9070101@meduna.org> Date: Tue, 15 Sep 2009 11:12:00 -0000 From: Stanislav Meduna User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: eCos Discussion Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated-User: stano@meduna.org X-Authenticator: dovecot_plain X-Spam-Score: -8.2 X-Spam-Score-Int: -81 X-Exim-Version: 4.69 (build at 30-Sep-2008 18:26:44) X-Date: 2009-09-15 13:11:55 X-Connected-IP: 78.141.95.31:2967 X-Message-Linecount: 39 X-Body-Linecount: 29 X-Message-Size: 1291 X-Body-Size: 939 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] I/O thread safety X-SW-Source: 2009-09/txt/msg00109.txt.bz2 Hi, I'd like to ask whether and how is the thread-safety of the I/O subsystem approached - is this a problem of application code, each subsystem, each driver,...? I am implementing a driver for a CAN controller connected via a SPI interface. Each CAN controller transaction requires a few separate SPI transactions that should not be interrupted by transactions done from another thread (this can be probably fixed to do everything in one SPI transaction, but I'd like to ask anyway). I am accessing the driver via the CYGPKG_IO_CAN layer. The reads are normally executed by a message event loop in one thread blocking until a CAN message arrives, the writes are done from another thread. To make things even more interesting both the SPI and the CAN device are interrupt-driven... What is the suggested approach to make this thread-safe? A pointer to some example code is enough. Thanks -- Stano -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss