1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 <2015> 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 <2015> 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Question about device support |
From: | Ralph Lange <[email protected]> |
To: | Florian Feldbauer <[email protected]> |
Cc: | EPICS Tech Talk <[email protected]> |
Date: | Tue, 26 May 2015 14:46:01 +0200 |
Hi Florian,Yet another thing to keep in mind is the level at which you want locking of things to happen. Usually (in the blocking case), a port driver locks its port, does the IO, then unlocks its port.
Some years ago at BESSY we were thinking how our CAN-Bus driver would fit the ASYN model. CANopen compliant, i.e. many nodes per bus (~30), many variables per node (~15), and some types of indexed variables with many values per variable (~120). The only thing that we wanted to be locked (between request and reply) was the variable, to avoid sending commands on two different indexes of the same variable without waiting for an answer. Something like that does not fit the ASYN model well. For each fully populated bus segment you would basically end up with ~450 instances of a blocking "variable" port driver, all talking to the same non-blocking lower level "bus" port driver. Starting 450 threads per bus made this look very unattractive. In the end we kept our patchwork non-ASYN driver, as (for this and other reasons) the rewriting effort was not justified well enough.
~Ralph