2021年Labview学习笔记（最全）(1).doc

reference死锁问题

LabVIEW中引用经常需要和“InPlaceElementStruc配tu合re使”用。InPlaceElementStructure对一种引用数据进行解决时，为了保证多线程安全，它会锁住引用指向数据；其他线程若需对同一数据做操作，必要能这个InPlaceElementStructure中所有代码执行完毕才可，这样就避免了多线程读写同一内存数据所产生竞争问题。

举例来说，下面这段程序执行时间是1秒：

而下面这段程序执行时间则是2秒：

由于第二段程序中两个InPlaceElementStructure必要顺序执行。

有了“锁住”这个操作，就有不小心导致死锁也许。例如对于同一数据引用，千万不能嵌套使用InPlaceElementStructure，否则就会死锁：

在上面这个示例中，程序运营至内层InPlaceElementStructure，就会停在这里等外

层InPlaceElementStructure运营结束，释放它锁住数据；而对于外层InPlace

ElementStructure来说，它内部所有代码要运营结束，它才结束。因而它们互相等待，导致了死锁。

PackedProjectLibraries2–与Library比较

ackedProjectLibrary从名字上来看，就是被包装好了ProjectLibrary。Project

Library是编程时候由程序员创立出来。例如下图这个工程，我在里面创立了一种叫做“MyAlgorithmLibrary.ll程ib。它包括两个VI，其中一种是私有。

PackedProjectLibrary并不是手工创立，她是通过一种项目生成规范，从Project

Library编译而来。例如上图项目，我创立了一种PackedLibrary类型生成规范。我

在这个生成规范中指定把“MyAlgorithmLibrary.ll译ibPackedProjectLibrary。

编译成果是在我指定途径下生成了一种名为“MyAlgorithmLibrary.lv文lip”。它后缀名仅比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可以缩短编译时间，由于PackedProject

Library中VI是已编译好，不会再随项目编译一遍。(这一条先这样写上，但我还需要再进一步研究一下)

LabVIEW中LVClass数据转换成XML格式问题

前一段时间，一种同事程序出了问题。她在程序中把一种LVClass类型数据转换成XML格式，再保存成文献。但是从文献中把数据转回成LVClass时，却出了问

题：在调用“UnflattenXML这”个函数时，程序有时出错，有时又不出错。她程序中使用了大量LVClass，并且它们之间有着复杂继承与包括关系，以至于花了两三天事件，才找出问题所在。其实是个简朴问题，只是在设计程序时她没故意识

到。

我做了一种简化程序，可以重现这个问题：

一方面，给一种子类对象设