Experimental Physics and
Industrial Control System

"Johnson, Andrew N." <[email protected]> · Wed, 7 May 2014 21:32:46 +0000

Hi Mark,

You could try adding a call to the gcc built-in routine __sync_synchronize(); after the last write to the asynUser structure. This implements a full memory barrier, which is equivalent to the two memory barriers inside the mutex operations. If this fixes it for ARM there is probably a better solution, but this will at least identify if this is the cause of the problem.

- Andrew

-- 
Sent from my iPad

> On May 7, 2014, at 7:52 PM, "Mark Rivers" <[email protected]> wrote:
> 
> Hi Andrew,
> 
> Thanks for the information.
> 
> The thread processing the record does the following in devMotorAsyn.c:
> 
> - Creates an asynUser structure (pasynManager->duplicateAsynUser)
> - Creates an private message structure (pasynManager->memMalloc)
> - Populates the private message structure with a command number, interface type, and dvalue which is the velocity, etc.
> - Copies the address of the private message structure to asynUser.userData
> - Calls pasynManager->queueRequest(&asynUser)
> - Returns
> 
> While this is executing the data is "private", no other thread has access to the address of the asynUser or the private message structure
> 
> pasynManager->queueRequest causes the asyn port driver thread for this port to run.  It is passed the address of the asynUser structure.  It executes the callback function in devMotorAsyn.c.  In that callback we see that some of the data in the private message structure is OK (the command and interface fields), but the dvalue field is 0, not the value it was set to above.
> 
> The asyn port driver is certainly taking a mutex when it runs, before it reads the data.  But I am not sure we are releasing a mutex after writing to the data, since it was not really "shared" before we called pasynManager->queueRequest?
> 
> Mark
> 
> 
> 
> -----Original Message-----
> From: Johnson, Andrew N. [mailto:[email protected]] 
> Sent: Wednesday, May 07, 2014 12:06 PM
> To: Mark Rivers
> Cc: J. Lewis Muir; [email protected]
> Subject: Re: Newport XPS-Q8 and Motor Record - armv5teb architecture
> 
> Mark,
> 
> What thread synchronization is used between the two tasks that are seeing different data? The ARM memory model is stricter than the Intel one, so the code must release a mutex after writing to shared data, and take a mutex before reading from shared data. It is even possible that the epicsRingBuffer code doesn't properly follow the ARM rules, I would try running the relevant libCom tests to check that. I can't research anything more about it right now (I'm on vacation), but it's something you might want to double check.
> 
> - Andrew
> 
> -- 
> Sent from my iPad
> 
>> On May 7, 2014, at 6:34 PM, "Mark Rivers" <[email protected]> wrote:
>> 
>> I don't think this has anything to do with the problem we are seeing on the ARM5.  
>> 
>> The problem we are seeing does not have to do with passing the status bits to the motor record, it has to do with passing information in pasynUser->userData.  This is an asyn issue, not a motor record issue.
>> 
>> Mark
>> 
>> 
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf Of J. Lewis Muir
>> Sent: Wednesday, May 07, 2014 11:29 AM
>> To: [email protected]
>> Subject: Re: Newport XPS-Q8 and Motor Record - armv5teb architecture
>> 
>>> On 5/7/14, 11:01 AM, Jens Eden wrote:
>>> I don't know if this is the cause of the problem, but even on a
>>> single architecture, you will need a correct entry in this switch in
>>> motorApp/MotorSrc/motor.h
>> 
>> Jens posted about this to the list in February:
>> 
>> http://www.aps.anl.gov/epics/tech-talk/2014/msg00158.php
>> 
>> From that thread, it sounds like the motor module needs some work to
>> eliminate assumptions about, as Till Straumann wrote, "what storage unit
>> the compiler uses, how adjacent bits are packed across a storage-unit
>> boundary and in what order bits are allocated (LSB->MSB or MSB->LSB)."
>> 
>> Lewis
>> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System