looking at hal_lib.c some more: the hal_set_lock() and hal_get_lock() functions are kind of misnomers IMO, all they do is set a global *flag* which is NOT a mutex or atomic for that matter, so it is advisory in nature and some of the routines in hal_lib.c report an error if some lock bit is set
for the same reason the halcmd lock and unlock commands are misnomers IMO too - the dont aquire or release the mutex, they set said flag however, the real locking and unlocking is always done with rtapi_mutex_get(&(hal_data->mutex)) and rtapi_mutex_give(&(hal_data->mutex)), so I dont quite see the value of those lock bits in the first place - if the idea was to allow for more parallelism due to finer-granular locks, that is defeated by having a single hal_data->mutex lateron in the first place IMO doing away with the set/get lock calls and data, and testing for locked condition with a call to rtapi_mutex_try() should give the same effect cleaner and for less bloat, but I might be overlooking something Maybe jmk can shed some light on the intent and purpose - Michael Am 20.07.2012 um 12:09 schrieb andy pugh: > On 20 July 2012 07:06, Philippe Frossard <[email protected]> wrote: > >> We are writting a little application in C inspired from different sources, >> We are create an Hal structure with hal_malloc, >> I would like to know if I need to use hal_set_lock or hal_get_lock to >> access this structure ? >> or if I can access this structure directly ... > > A search through the source code for hal_set_lock might be > instructive. I can say for sure it doesn't appear in any of my code. > > hal_set_lock is used 14 times and only in halcmd and halrmt. (ie is > interfaces running concurrently in userspace) > Considering that HAL functions are called in strict sequence I don't > think it is necessary to set the locks in general. > > -- > atp > If you can't fix it, you don't own it. > http://www.ifixit.com/Manifesto > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
