Labview学习笔记.doc

(完整word版)Labview学习笔记(完整word版)Labview学习笔记(完整word版)Labview学习笔记reference死锁问题LabVIEW中的引用经常需要和“InPlaceElementStructure”配合使用。InPlaceElementStructure对一个引用的数据进行处理时,为了保证多线程安全，它会锁住引用指向的数据;其它线程若需对同一数据做操作，必须能这个InPlaceElementStructure中所有代码执行完毕才可，这样就避免了多线程读写同一内存数据所产生的竞争问题。举例来说，下面这段程序的执行时间是1秒：HYPERLINK"http：//ruanqizhen。files.wordpress.com/2011/05/image.png”而下面这段程序的执行时间则是2秒：HYPERLINK"http://ruanqizhen.files。wordpress.com/2011/05/image1。png"因为第二段程序中的两个InPlaceElementStructure必须顺序执行。有了“锁住”这个操作，就有不小心造成死锁的可能。比如对于同一数据的引用,千万不能嵌套使用InPlaceElementStructure，否则就会死锁：HYPERLINK"http：//ruanqizhen.files。wordpress.com/2011/05/image2.png”在上面这个示例中,程序运行至内层的InPlaceElementStructure，就会停在这里等外层InPlaceElementStructure运行结束，释放它锁住的数据;而对于外层InPlaceElementStructure来说,它内部的全部代码要运行结束，它才结束。因而它们相互等待,造成了死锁。PackedProjectLibraries2–与Library的比较ackedProjectLibrary从名字上来看，就是被包装好了的ProjectLibrary。ProjectLibrary是编程时候由程序员创建出来的.比如下图这个工程，我在里面创建了一个叫做“MyAlgorithmLibrary.lvlib”的工程库。它包含两个VI,其中一个是私有的。PackedProjectLibrary并不是手工创建的,他是通过一个项目的生成规范，从ProjectLibrary编译而来的。比如上图的项目，我创建了一个PackedLibrary类型的生成规范。我在这个生成规范中指定把“MyAlgorithmLibrary。lvlib”编译成PackedProjectLibrary。编译的结果是在我指定的路径下生成了一个名为“MyAlgorithmLibrary.lvlibp”的文件.它的后缀名仅比PackedLibrary多了一个字母p。双击这个文件,可以打开它，看到他里面包含的VI：如果需要在其它项目中使用到这个PackedProjectLibrary，我们可以直接把它加到另一个项目中去，下图是一个演示项目：PackedProjectLibrary看上去和ProjectLibrary非常相似,用法也完全相同。PackedProjectLibrary与ProjectLibrary都是将功能相关的一组VI封装起来的方法；库中的VI可以具有层次机构；库中的VI都带有名字空间，名字空间是带有后缀名的库名；都可以方便的放在项目管理器里使用尽管它们十分相似，PackedProjectLibrary与ProjectLibrary相比，还是有一些明显区别的:PackedProjectLibrary是通过编译生成的；PackedProjectLibrary中的VI是编译后产生的，它们不能被修改；PackedProjectLibrary包含有私有VI,但用户无法看到也不能使用它们；PackedProjectLibrary把VI，。lvlib以及其它用到的文件都打成一个压缩包，用户在磁盘上就只能看到一个。lvlibp文件,看不到VI文件；PackedProjectLibrary很适合作为最终产品发布给用户使用;在项目中使用PackedProjectLibrary可以缩短编译时间，因为PackedProjectLibrary中的VI是已编译好的，不会再随项目编译一遍.(这一条先这样写上，但我还需要再深入研究一下）LabVIEW中LVClass数据转换成XML格式的问题前一段时间，一个同事的程序出了问题。他在程序中把一个LVClass类型的数据转换成XML格式，再保存成文件.但是从文件中把数据转回成LVClass时，却出了问题：在调用“UnflattenXML”这个函数时，程序有时出错，有时又不出错.他的程序中使用了大量的LVClass，并