Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: Deadlock when using asyn with StreamDevice. (Was: Deadlock when using asyn?)
From: Dirk Zimoch <dirk.zimoch@psi.ch>
To: "Rees, NP \(Nick\)" <nick.rees@diamond.ac.uk>
Cc: Eric Norum <norume@aps.anl.gov>, EPICS tech-talk <tech-talk@aps.anl.gov>
Date: Fri, 04 Aug 2006 11:05:55 +0200
Hi Nick, Eric,

here is some background, what StreamDevice does with intrCallbackOctet:

If a record which uses StreamDevice is in "I/O Intr" scan mode, it should get input asynchronously, e.g. from a device which sends messages periodically without beeing polled. This is not supported by asynDriver. One can only receive data via intrCallbackOctet if someone calls read. Thus, StreamDevice polls periodically for new input if no other asynUser calls read: after a timer expires, it queues to do its own read. However, if another user called read meanwhile, so that intrCallbackOctet is called, StreamDevice cancels the poll. I.e. it cancels the timer and the queue request.

There seems to be a problem if the read in question was synchronous. I will check that.

Dirk


Rees, NP (Nick) wrote:
Eric,

The short answer is I don't know. That is in StreamDevice, and the
reason why I sent out the email is that I thought I had simplified the
system down to the stage where I had eliminated StreamDevice.  However,
in looking at it I ended up using the wrong startup script and
StreamDevice activity was still included.

Now I see this the problem seems to be that streamDevice doesn't seem to
work well with tasks using asynOctetSyncIO on the same asyn port. I am
using StreamDevice-2-1-patch20060717 off the SLS website.
intrCallbackOctet looks like:

void intrCallbackOctet(void* /*pvt*/, asynUser *pasynUser,
    char *data, size_t numchars, int /*eomReason*/)
{
    int wasQueued;
    AsynDriverInterface* interface =
        static_cast<AsynDriverInterface*>(pasynUser->userPvt);
    if (interface->ioAction == AsyncRead ||
        interface->ioAction == AsyncReadMore)
    {
    // cancel possible readTimeout or poll timer
        interface->cancelTimer();
    // cancel possible read poll
        pasynManager->cancelRequest(interface->pasynUser, &wasQueued);
        interface->asynReadHandler(data, numchars);
    }
}

I suppose I am now waiting for Dirk to help :-).

Cheers,

Nick Rees
Principal Software Engineer Phone: +44 (0)1235-778430
Diamond Light Source Fax: +44 (0)1235-446713 -----Original Message-----
From: Eric Norum [mailto:norume@aps.anl.gov] Sent: 03 August 2006 18:27
To: Rees, NP (Nick)
Cc: EPICS tech-talk
Subject: Re: Deadlock when using asyn?



Why is your intrCallbackOctet routine calling cancelRequest?



On Aug 3, 2006, at 11:58 AM, Rees, NP (Nick) wrote:



Hi,



I have an asynSerial port that on VxWorks that is accessed by two tasks. The first calls asynOctetSyncIO->writeRead in a private driver background thread and the second access is in the asyn port thread using asynRecord. The two tasks seem to deadlock over access to the two semaphores: mutex pport->synchronousLock, and event puserPvt->callbackDone.


Has anyone seen anything similar? What are the rules between mixing asynOctetSyncIO and normal calls in the asynPort thread? I thought that the lockPort in asynOctetSyncIO->writeRead was all that was needed.


Further information:



1. Asyn version: 4-6



2. Driver background thread stack trace:



#0 0x2276dc in semBTake () #1 0x2283ac in semTake () #2 0x1e74eb78 in cancelRequest (pasynUser=0x1ecf4168, wasQueued=0x1ec9a18c) at ../../asyn/asynDriver/asynManager.c:1458 #3 0x1e72f0f8 in intrCallbackOctet (pasynUser=0x1ed179d8, data=0x1ed4c130 "0\r", numchars=2) at ../AsynDriverInterface.cc:780 #4 0x1e75b3f0 in callInterruptUsers (pasynUser=0x1ed4c498, pasynPvt=0x1ed4c5f0, data=0x1ed4c130 "0\r", nbytesTransfered=0x1ec9a294, eomReason=0x1ec9a370) at ../../asyn/interfaces/asynOctetBase.c:218 #5 0x1e75b770 in readRaw (drvPvt=0x1ed4c7e0, pasynUser=0x1ed4c498, data=0x1ed4c130 "0\r", maxchars=600, nbytesTransfered=0x1ec9a294, eomReason=0x1ec9a370) at ../../asyn/interfaces/asynOctetBase.c:282 #6 0x1e762bec in readIt (ppvt=0x1ed4c580, pasynUser=0x1ed4c498, data=0x1ed460ec "", maxchars=80, nbytesTransfered=0x1ec9a36c, eomReason=0x1ec9a370) at ../../asyn/miscellaneous/asynInterposeEos.c:241 #7 0x1e75d300 in writeRead (pasynUser=0x1ed4c498, write_buffer=0x1ed4609c "M161", write_buffer_len=4, read_buffer=0x1ed460ec "", read_buffer_len=80, timeout=1, nbytesOut=0x1ec9a368, nbytesIn=0x1ec9a36c, eomReason=0x1ec9a370) at ../../asyn/interfaces/asynOctetSyncIO.c:342 #8 0x1e6f4b84 in drvPmacMbxWriteRead (card=0, writebuf=0x1ed4609c "M161", readbuf=0x1ed460ec "", errmsg=0x1ed4613c "") at ../drvPmac.c:1580 #9 0x1e6f52ec in drvPmacMbxTask (card=0) at ../drvPmac.c:1746 #10 0x231f7c in vxTaskEntry ()


3. Line 1458 in asynManager.c: epicsEventMustWait(puserPvt->callbackDone);


4. Information on puserPvt->callbackDone:



ioc135 -> semShow 0x1ed113e0,5



Semaphore Id : 0x1ed113e0 Semaphore Type : BINARY Task Queuing : FIFO Pended Tasks : 1 State : EMPTY Options : 0x0 SEM_Q_FIFO


VxWorks Events -------------- Registered Task : NONE Event(s) to Send : N/A Options : N/A


Pended Tasks ------------ NAME TID PRI TIMEOUT ---------- -------- --- ------- pmacMbx0 1ec9a440 45 0


5. Stack trace for asynPort thread:



#0 0x229348 in semMTake () #1 0x2283ac in semTake () #2 0x1e8799ac in epicsMutexLock () #3 0x1e74b900 in portThread (pport=0x1ed4fcc0) at ../../asyn/asynDriver/asynManager.c:769 #4 0x1e882c68 in createFunction () #5 0x231f7c in vxTaskEntry ()


6. Line 769 in asynManager.c is: epicsMutexMustLock(pport->synchronousLock);


7. Information on the pport->synchronousLock mutex is:



ioc135 -> epicsMutexShow 0x1ed4fbe0,5 epicsMutexId 0x1ed4fbe0 source ../../asyn/asynDriver/asynManager.c line 1714


Semaphore Id : 0x1ed4fc10 Semaphore Type : MUTEX Task Queuing : PRIORITY Pended Tasks : 1 Owner : 0x1ec9a440 (pmacMbx0) Options : 0xd SEM_Q_PRIORITY SEM_DELETE_SAFE SEM_INVERSION_SAFE


VxWorks Events -------------- Registered Task : NONE Event(s) to Send : N/A Options : N/A


Pended Tasks ------------ NAME TID PRI TIMEOUT ---------- -------- --- ------- PMAC_ASC_0 1ed4f7b0 149 0




Any help would be greatefully received.



Cheers,



Nick Rees Principal Software Engineer Phone: +44 (0)1235-778430 Diamond Light Source Fax: +44 (0)1235-446713



-- Dr. Dirk Zimoch Swiss Light Source Computing and Controls Paul Scherrer Institut phone +41 56 310 5182 fax +41 56 310 4413

References:
Deadlock when using asyn with StreamDevice. (Was: Deadlock when using asyn?) Rees, NP (Nick)

Navigate by Date:
Prev: Deadlock when using asyn with StreamDevice. (Was: Deadlock when using asyn?) Rees, NP (Nick)
Next: Devices Which Send Unsolicited Messages Steven Banks
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Deadlock when using asyn with StreamDevice. (Was: Deadlock when using asyn?) Rees, NP (Nick)
Next: Re: Deadlock when using asyn with StreamDevice. (Was: Deadlock when using asyn?) Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·