Home >> Support Board

Support Board

Date/Time: Fri, 29 Nov 2024 05:34:22 +0000

How to Post a Message for Support

[Programming Help] - persistent variables simultaneous assignments between charts? (across 2+ chart threads..)

View Count: 438

[2023-03-02 05:41:08] #1 [Go To First Post]
User133994 - Posts: 80
Support, I assume each chart has its own thread...so that means there is a possibility of simultaneous assignments to persistent variables using a sc.SetPersistentForChartStudy function on 2 different charts which reference the same persistent variable (i.e. shared variables). From here: Chart Study Persistent Variable Functions Your documentation says: If setting or getting a persistent variable in another chart (Source chart), then when that Source chart is updated for any reason, the chart that made the reference to it (Destination chart), will have its studies calculated. In this way your study on the Destination chart will be aware of the changes to the persistent variable in a Source chart. When running a multiple chart Back Test, charts will be calculated in the proper order as well. Can you please elaborate how, for example, these simultaneous assignment operations won't collide: source chart #1 with source persistent variable A: @1:00:00 uses sc.SetPersistentForChartStudy on variable A to set it to 34 destination chart #2 with reference to source's persistent variable A: @1:00:00 uses sc.SetPersistent*ForChartStudy on variable A to set it to 100 which SetPersistent will win? 34 or 100? what will be persistent variable A's value @1:00:01? will it be the same on chart #1 and #2 @1:00:01? what if chart #1 is an 88 trades (tick) chart and #2 is a 5 min chart, and it just so happens they both want to set persistent variable A at the same time, does that change anything? Maybe I am misunderstanding how the chart threading works or persistent variable assignments work across charts? An example explaining how/why this will never occur would also be helpful--if that is the case. Perhaps you have an internal locking mechanism that avoid these scenarios; or, you have designed around it. Please let me know the design or locking mechanism so I can use it properly. Maybe it is built-in to the ACSIL system and I'm missing it. Thanks in advance..

[2023-03-02 10:43:48] #2 [Go To First Post]
User431178 - Posts: 544
I assume each chart has its own thread No, all done on primary thread Working with ACSIL Arrays and Understanding Looping: Study Function Calling and Threads High CPU Usage \| Inactive User Interface \| Poor Performance \| Long Time to Load Chart Data \| Charts Reloading Often: 30.37 - Determining CPU Load from Sierra Chart Date Time Of Last Edit: 2023-03-02 10:44:00

[2023-03-02 12:53:30] #3 [Go To First Post]
Sierra_Chart Engineering - Posts: 17220
Regarding post #1, ACSIL studies are all executing within the same thread per instance of Sierra Chart. So whatever chart sets a persistent variable last, will have set its most recent value. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2023-03-02 12:54:14

[2023-03-02 17:22:53] #4 [Go To First Post]
User133994 - Posts: 80
Thanks for the quick response. I understand that each instance operates in 1 thread from a "studies" perspective across all charts. I assume this is for all charts in the same chartbook. So does whatever chart sets a persistent variable last mean this is impossible: source chart #1 with source persistent variable A: @1:00:00 uses sc.SetPersistentForChartStudy on variable A to set it to 34 destination chart #2 with reference to source's persistent variable A: @1:00:00 uses sc.SetPersistentForChartStudy on variable A to set it to 100 And, does that mean that chart #1 will never "be able" to modify a shared persistent variable at the exact same time as chart #2? What is the sequencing mechanism for apparent "simultaneous" events? Who gets priority and why? Will chart #2 be blocked from modifying the shared persistent variable, how, when? If they both request the sc.SetPersistent at the same time? Or is there a "queue" of requests and thus it will never be the exact same time. How does that queue work? A simple 2 chart 1 persistent shared variable example will be a great help in understanding this--if you are able. Thanks in advance. Follow-on question: What about different chartbooks--same thread also? Maybe there aren't shared persistent variables across chartbooks, even though it might be in the same thread?

[2023-03-02 19:43:36] #5 [Go To First Post]
ForgivingComputers.com - Posts: 960
Or is there a "queue" of requests Sort of. Each study is a copy of a DLL that is tied directly into the main Sierra Chart thread. Therefore, there are no simultaneous updates of the other chart's persistent variables, they all happen round-robin as part of each chart and the studies attached to them.

To post a message in this thread, you need to log in with your Sierra Chart account: