我是否应该在LabVIEW中也将预分配VI中的子VI设置为预分配? [英] Should I make subVIs in preallocated VI as preallocated too in LabVIEW?

查看:373
本文介绍了我是否应该在LabVIEW中也将预分配VI中的子VI设置为预分配?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个VI,其执行类型设置为预先分配的克隆可重入. 在VI中,我有几个SubVI.子VI的执行类型应设置为与主VI相同吗?

I have got a VI which execution type is set to be as preallocated clone reentrant. In the VI i have several SubVIs. Should I set the execution type of SubVIs the same as in the main VI?

谢谢

推荐答案

将VI设置为可重入并不会自动使其子VI重入-如果这样做,这将破坏非重入VI的某些用例,例如序列化对单个资源的访问或维护调用之间的存储状态数据.因此,要确定子VI是否需要重入,只需与确定父VI是否需要重入时所考虑的问题相同.

Setting a VI to be reentrant doesn't automatically make its subVIs reentrant - if it did, this would break some of the use cases for non-reentrant VIs, such as serialising access to single resources or maintaining stored state data between calls. So to decide whether a subVI needs to be reentrant, you just have to consider the same issues as you did when deciding whether the parent VI needed to be reentrant.

我在

I found a good summary of the considerations in this post by GregR on the LAVA forum, which still holds true as far as I can see (fully reentrant was the older LabVIEW term for preallocated clone reentrant):

  • 任何保持状态的VI都必须是不可重入的或完全不可重入的 可重入的内容取决于其对该州的要求.
  • 如果存在不能真正同时调用的VI,则应 保持非重入状态.这可能是诸如配置对话框或文件修改之类的事情.非可重入VI是序列化对单实例资源的访问的最简单方法之一.
  • 属于该部分的任何VI 对于性能至关重要的代码路径,应该完全重入.这样可以避免性能关键代码或非性能关键代码的多个并行实例之间的同步点妨碍性能关键代码.
  • 除此之外,您可以开始偏爱非可重入或共享可重入以减少内存使用.
  • [...]总是快速执行的VI可以视为不可重入.请记住,始终快速执行的VI与通常快速执行的VI之间存在差异.进行异步通信的任何事情(网络,队列等)都应被认为是缓慢的,因为它可能花费比预期更长的时间.
  • 使从很多地方调用的VI共享可重入而不是完全可重入会稍微增加执行时间,但会大大增加执行时间 减少所需实例的数量,从而减少内存使用量.
  • Any VI that maintains state needs to be either non-reentrant or fully reentrant depending on its requirements for that state.
  • If there are any VIs that truly can't be called at the same time, those should stay non-reentrant. This could be things like configuration dialogs or file modification. Non-reentrant VIs are one of the easiest ways to serialize access to single instance resources.
  • Any VI that is part of a performance critical code path probably should be made fully reentrant. This avoids synchronization points between multiple parallel instances of performance critical code or non-performance critical code getting in the way of performance critical code.
  • Beyond that you can start to favor non-reentrant or shared reentrant to reduce memory usage.
  • [...] VIs that always execute quickly can be considered for leaving as non-reentrant. Keep in mind that there is a difference between a VI that always executes quickly and one that typically executes quickly. Anything that does asynchronous communication (networking, queues, ...) should be considered slow, because it could take longer than expected.
  • Making VIs that are called from a lot of places shared reentrant instead of fully reentrant will slightly increase execution time but can greatly reduce the number of instances required and thus memory usage.

这篇关于我是否应该在LabVIEW中也将预分配VI中的子VI设置为预分配?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆