Прошу подсказать, может кто-то сталкивался.
Скрипты на онлайне, которые используют статические поля периодически выдают левые данные. На истории все всегда в порядке. По всей видимости значения статпеременных самопроизвольно сбрасываются или переписываются. С чем это связано? Нехватка оперативки? Что с этим можно сделать?
PS Все поля private.

А вы понимаете что такое статическое поле? И как оно работает? Предлагаю вникнуть в сей вопрос и изложить кратко здесь.

Ок. Начнем издалека.)))
Статическое поле принадлежит классу, а не объекту класса. Создается статическим конструктором один раз и является общим для всех экземпляров класса. Применительно к ТСЛАБ. Когда исполняется Executive новый объект статического поля не создается. Это позволяет сохранять данные между пересчетами скрипта.

Чудес не бывает, если значение изменяется, то значит "кто-то" его изменил. Проверяйте логику обновления этих полей. Также, все усложняется из-за многопоточности исполнения скриптов лабой.

Я предполагаю, что если есть ошибки в логике, то они есть всегда. Т.е. ошибка бы проявлялась бы постоянно. А не время от времени и сама бы пропадала иногда.

Два параллельно исполняющихся скрипта запросто могут ИНОГДА конкурировать за значение в одной ячейке памяти.

У меня вот аналогичная версия происходящего. Как это можно проверить/исправить?

Традиционный способ поиска проблемы в многопоточном приложении - это вести лог событий. Т.е. в вашем случае, писать в лог каждый раз, когда изменяете значение переменной.
А можете тупо (или не тупо) временно блокировать доступ к переменной на время работы скрипта. См. документацию по C# оператор lock

Вот вам и ответ на вопрос в топе. Две копии скрипта и одно статическое поле. Труляля имеем трабл.

А то что писалось про lock уже ошибочно. Это не нужно. Просто помните что статическое поле у вас ОДНО на ВСЕ копии скрипта.

Можно попросить раскрыть идею начет копии скрипта? Уже не помню где, по моему на форуме, читал что у ТСЛАБ отдельный поток на каждый исполняемый скрипт.
Тогда, по идее, с одним потоком блокировки не нужны.

блокировки не нужны. Тут дезинформация. Блокировки не помогут вообще в проблеме со статическим полем.

Тут у вас проблема понимания сути статического поля. Все ваши скрипты будут разделять ОДНО поле. Оно будет ОБЩИМ. В этом суть статических членов класса. Значит все скрипты будут друг другу мешать запихивая в это поле каждый раз свое значение.

Я раньше на уроках про статик поля рассказывал но перестал именно из за возможных проблем с ним. используйте кэш скриптов. все подробно расписано на нашем сайте. почитайте.

Так поле объявлено в конкретном классе. Почему оно общее?

Скрипт есть экземпляр класса. Две копии скрипта есть два экземпляра класса. Почему для двух экземпляров одно поле? Тут отправляю к документации по статическим членам класса.

Мда, забавно.
Про использование lock у меня все правильно написано. Ни ошибок, ни дезинформации нет. Вопрос только где и как блокировку использовать.

А вот про то, что статическое поле одно на все скрипты, это вы ошибаетесь. Лаба каждый скрипт, и даже копии одного и того же скрипта, загружает и выполняет как отдельную самостоятельную сборку. Т.е. создает в памяти копии кода скрипта в виде отдельных сборок. Соответственно и статических переменных, определенных в скрипте, в памяти будет столько, сколько копий скрипта запущено. Т.е. каждый скрипт будет использовать свое статическое поле.
Это что касается статических переменных в теле скрипта. А в случае нахождения статического поля в сборке с индикаторами, загружаемыми лабой при ее старте, все скрипты, использующие это поле, будут обращаться к одному и тому же полю (ячейке памяти). Тогда разные скрипты могут одновременно обновлять это поле и, соответственно, ВОЗМОЖНО, нужна его блокировка.
Между пересчетами, значение статического поля не меняется, но стоит вам перезапустить скрипт, как использоваться будет уже другая сборка и другое поле и ранее сохраненные в него значения будут недоступны.

По поводу потоков: да, каждый скрипт исполняется в своем потоке. В деталях, конечно же, все несколько сложнее.

Приведите код своего скрипта, использующего статическую переменную. Удалите все, что ненужно (суть стратегии), но оставьте пример, как вы используете эту переменную, посмотрим.

Проблемные поля в кубике индикатора. Используются для сохранения исторических данных в кубике с последовательной обработкой. Кстати только задумался, что на скриптах никогда не сталкивался с такими проблемами.

Трудно посоветовать что-либо еще.
Мне кажется, надо проверять логику использования статпеременной или пытаться пропускать некорректные значение в индикаторе, если такое возможно.

Индикатор с последовательной обработкой все усложняет, даже блокировать доступ других скриптов к статпеременной в таком индикаторе не получится. Может лучше сделать индикатор с потоковой обработкой (который рассчитывается в начале пересчета скрипта)? А для последовательной обработки (в цикле по свечкам) использовать обновляемое значение или другой индикатор инициализируемый значением из первого.

Может быть в лаборатории открыт и "обновляется в реальном времени" скрипт который тоже использует этот индикатор?

Чем поможет лок в проблеме когда у человека одно поле разделяется несколькими скриптами? Лок может помочь только избежать ошибок совместного доступа и все. Но никак не избавит от самого факта этого доступа.


да так и есть, если копать в детали. Но этим вы только больше запутали проблему . Совет был просто отказаться от статических полей и все.


ПС: просто не нужно использовать стат полей и все. Ищите другие подходы, более стандартные для тслаба.