var 作用域单例可能存在竞争条件？
我与应用程序范围的单例可能存在竞争条件。但是，我认为通过定义函数级别变量，这不会成为问题。
<!--- Calling page --->
<cfset url.UUID = createUUID() />
<cfset application.UUIDBot.displayUUID() />
<!--- UUIDbot --->
<cfcomponent>
<cffunction name="displayUUID">
<cfset var rc = {} />
<cfset rc.position = url.uuid />
<cfinclude template="displayUUID.cfm" />
</cffunction>
</cfcomponent>
<!--- displayUUID.cfm --->
<cfoutput>#rc.position#</cfoutput>
displayUUID.cfm 是否有可能不显示 URL 中的 UUID？
I have a possible race condition with an application scoped singleton. However, I thought that by defining a function level variable that this would not be a problem.
<!--- Calling page --->
<cfset url.UUID = createUUID() />
<cfset application.UUIDBot.displayUUID() />
<!--- UUIDbot --->
<cfcomponent>
<cffunction name="displayUUID">
<cfset var rc = {} />
<cfset rc.position = url.uuid />
<cfinclude template="displayUUID.cfm" />
</cffunction>
</cfcomponent>
<!--- displayUUID.cfm --->
<cfoutput>#rc.position#</cfoutput>
Is it possible that displayUUID.cfm would not display the UUID in the URL?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
问题将出现在您未共享的代码中，该代码通过 displayUUID.cfm 文件包含。 displayUUID 中的代码不是线程安全的（我猜测）。该代码还需要使用“var”来本地化变量，或者在引用前加上“local”前缀。以确保它们是本地范围的。
底线：当您在函数中使用 cfinclude 时，包含的代码也必须是线程安全的。
The problem is going to be found in the code you have not shared, that which is included via the displayUUID.cfm file. The code within the displayUUID is not thread safe (I am guessing). That code also needs to use "var" to localize the variables--or--prefix your references with "local." to ensure they are local scopped.
Bottom line: When you use cfinclude within a function the included code must also be thread safe.
我读过隐式结构符号本身不是线程安全的。
http://www.barneyb.com/barneyblog/2009/06/19/coldfusion-struct-literals-are-not-thread-safe-cfml-ones-are/
尝试将其更改为使用锁和 StructNew。
I have read that implict struct notation itself is not thread-safe.
http://www.barneyb.com/barneyblog/2009/06/19/coldfusion-struct-literals-are-not-thread-safe-cfml-ones-are/
Try changing it to use a lock and a StructNew.
您在那里发布的内容是线程安全的。结构体的线程安全问题发生在分配先前指向空的内存块时。由于您使用的内置 URL 范围/结构已经具有有效的地址空间，因此这不应该是问题。
然而，您可能会遇到逻辑和程序执行时间的问题。
也就是说，我确实质疑你这里的推理和设计。它引发了很多危险信号。
cf 包括？为什么？我担心您正在走上动态包含的肮脏道路。
What you've posted there is thread safe. The issue of thread safety with structs occurs on assignment of a previously null pointed piece of memory. Since you're using the built in URL scope / struct which already has valid address space, this shouldn't be an issue.
You may however have issues with the logic and procedural execution timing.
That said, I do question the reasoning and design of what you have here. It raises a lot of red flags.
cfinclude? why? I fear you're going down the nasty road of dynamic includes.