Labview学习笔记题材.docx

reference 死锁问题 LabVIEW中的引用经常需要和“In Place Element Structure”配合使用。In Place Element Structure 对一个引用的数据进行处理时，为了保证多线程安全，它会锁住引用指向的数据；其它线程若需对同一数据做操作，必须能这个In Place Element Structure中所有代码执行完毕才可，这样就避免了多线程读写同一内存数据所产生的竞争问题。 举例来说，下面这段程序的执行时间是1秒：  而下面这段程序的执行时间则是2秒：  因为第二段程序中的两个In Place Element Structure必须顺序执行。 有了“锁住”这个操作，就有不小心造成死锁的可能。比如对于同一数据的引用，千万不能嵌套使用In Place Element Structure，否则就会死锁：  在上面这个示例中，程序运行至内层的In Place Element Structure，就会停在这里等外层In Place Element Structure运行结束，释放它锁住的数据；而对于外层In Place Element Structure来说，它内部的全部代码要运行结束，它才结束。因而它们相互等待，造成了死锁。 Packed Project Libraries 2 –与Library的比较 acked Project Library 从名字上来看，就是被包装好了的Project Library。Project Library 是编程时候由程序员创建出来的。比如下图这个工程，我在里面创建了一个叫做“My Algorithm Library.lvlib”的工程库。它包含两个VI，其中一个是私有的。 Packed Project Library 并不是手工创建的，他是通过一个项目的生成规范，从 Project Library 编译而来的。比如上图的项目，我创建了一个Packed Library类型的生成规范。我在这个生成规范中指定把“My Algorithm Library.lvlib”编译成Packed Project Library 。 编译的结果是在我指定的路径下生成了一个名为“My Algorithm Library.lvlibp”的文件。它的后缀名仅比Packed Library多了一个字母p。 双击这个文件，可以打开它，看到他里面包含的VI： 如果需要在其它项目中使用到这个Packed Project Library，我们可以直接把它加到另一个项目中去，下图是一个演示项目： Packed Project Library 看上去和 Project Library 非常相似，用法也完全相同。 Packed Project Library 与 Project Library ? 都是将功能相关的一组VI封装起来的方法； ? 库中的VI可以具有层次机构； ? 库中的VI都带有名字空间，名字空间是带有后缀名的库名； ? 都可以方便的放在项目管理器里使用 尽管它们十分相似，Packed Project Library 与 Project Library 相比，还是有一些明显区别的： ? Packed Project Library 是通过编译生成的； ? Packed Project Library 中的VI是编译后产生的，它们不能被修改； ? Packed Project Library 包含有私有VI，但用户无法看到也不能使用它们； ? Packed Project Library 把VI，.lvlib以及其它用到的文件都打成一个压缩包，用户在磁盘上就只能看到一个.lvlibp文件，看不到VI文件； ? Packed Project Library 很适合作为最终产品发布给用户使用； ? 在项目中使用Packed Project Library 可以缩短编译时间，因为Packed Project Library 中的VI是已编译好的，不会再随项目编译一遍。(这一条先这样写上，但我还需要再深入研究一下) LabVIEW中LVClass数据转换成XML格式的问题 前一段时间，一个同事的程序出了问题。他在程序中把一个LVClass类型的数据转换成XML格式，再保存成文件。但是从文件中把数据转回成 LVClass时，却出了问题：在调用“Unflatten XML”这个函数时，程序有时出错，有时又不出错。他的程序中使用了大量的LVClass，并且它们之间有着复杂的继承与包含关系，以至于花了两三天的事 件，才找出问题所在。其实是个简单的问题，只是在设计程序时他没有意识到。 我做了一个简化的程序，可以重现这个问题： 首先，给一个子类的对象设置一些数据。然后把它当做父类类型的数据，平化成