[Bacnet4linux-developer] Blocking Calls and Threads

[Steve K. <st...@ka...>]

Hi Coleman,

> I'm working on getting the read_property function to be a  
> blocking call in B4L.  I've accomplished this using  
> threads (the mechanism to receive data is multi-threaded  
> now instead of the select() in the main loop).  So, I  
> accomplished the blocking mechanism using condition  
> variables.    

Okay.  I suppose that we need to think about making the rest of the code 
thread safe, which it currently is not (i.e. globals and function static 
variables).

> So, here's what happens now.  When read_property is  
> called, it blocks until the condition variable gets set by  
> receive_readpropertyACK.  It only blocks for the APDU  
> Timeout.  So, it either gets an ACK or times out.    
>   
> What I'm thinking of doing is making a common structure  
> that gets initialized and allocated by read_property and  
> filled by receive_readpropertyACK.  Do you have any  
> suggestions as to what should go into this function?  
>   
> So far, I have the easy stuff:  object-id, property-id,  
> device-id, datatype, and value.  The problem with this  
> approach though is accounting for things like complex  
> types (recipient-list comes to mind).  Do you have any  
> ideas on this?  

So what you are saying is having something like:

char *pReadPropertyResult; // memory allocated by service

pReadPropertyResult = ReadProperty(device_instance, object_type, 
object_instance, property_identifer, property_index);

if (pReadPropertyResult)
{
   PrintServiceInfo(pReadPropertyResult);
   free(pServiceInfo);
}

The pReadPropertyResult could be:

* The raw data returned by the ReadProperty service (Object Identifier, 
Property Identifier, Property Array Index, Property Value)

* Above with just the Property value as the raw data

* Has object-id, property-id,  datatype, and value (and perhaps number 
of values in the case of a list).  The value portion could be stored as 
raw data, and we can create decoding functions that can be used based on 
datatype.

The problem, as you say, comes in for complex datatypes.  Perhaps 
turning the existing primitive datatype tags into enumerations, and 
adding the complex types based on their tags (they are unique, aren't 
they?).  So instead of datatype, store the tag (which is really the 
datatype) and includes the complex datatypes.  If the value is raw, than 
you can have a function that returns the datatype, and other functions 
that decode the raw data for each data type.

Best Regards,

Steve
-- 
http://kargs.net/