The 1-wire bus can only do a single thing at a time. A threaded application approach does not help here, you will always have the latency on the bus, which is rather high even compared to other buses (e.g. RS485 with MODBUS as the protocol stack). Therefore the potential speed gain even on the slowest master from a threaded approach, which does not necessarily mean a speed gain, is orders of magnitude lower than the hardware and protocol needs of the 1-wire bus.
Doma On 10/22/2010 07:40 PM, Joshua J. Kugler wrote: > On Friday 22 October 2010, Paul Alfille elucidated thus: >>> 2010/10/22 Joshua J. Kugler<jos...@azariah.com> >>> >>>> Reading through the Python module, there doesn't seem to be any >>>> kind of lock or semaphore preventing simultaneous reads. Is there >>>> such a thing at the libow C level? >> I can't speak for the python module -- there may be threading issues >> in global variables or io code. >> >> The underlying libow is definitely thread safe for calls to read. >> write and list directories. Actually we wrap locks around slave >> access, and bus master access (since there can be some interspersing >> of communication) as well as locks everything for dynamic additions >> of new bus masters, scanning the usb or mdns system, and cache >> additions and deletions. >> >> Obviously, since the entire library is linked in, calls to low-level >> routines might not be properly serialized, but linking at a higher >> level is safe (that's what owcapi does). > So, what I'm understanding is: there is *NO* speed advantage to > threading reading retrievals, since all calls are serialized by the > library. > > Is that correct? > > j > ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
