Threading Notes (Papyrus) - История изменений

Admin в 06:13, 25 августа 2015

2015-08-25T06:13:36Z

Admin в 05:57, 25 августа 2015

2015-08-25T05:57:05Z

Admin в 19:57, 23 апреля 2012

2012-04-23T19:57:37Z

Admin: /* Другой пример */

2012-03-30T11:19:56Z

‎Другой пример

Admin: /* Другой пример */

2012-03-30T10:59:39Z

‎Другой пример

Admin: /* Примечание о прослеживании "GoToState()" */

2012-03-30T10:56:13Z

‎Примечание о прослеживании "GoToState()"

Admin: /* Поточность: Базовый Пример */

2012-03-30T10:50:32Z

‎Поточность: Базовый Пример

Admin: /* Поточность */

2012-03-30T10:48:57Z

‎Поточность

Admin: /* Поточность */

2012-03-30T10:47:35Z

‎Поточность

Admin: /* Поточность */

2012-03-30T10:00:08Z

‎Поточность

@@ Строка 12: / Строка 12: @@
 Если же несколько вещей(потоков) пытаются одновременно управлять скриптом, то они выстраиваются в форме "очереди"(англ. queue), состоящей из всех этих потоков, которые по существу ждут очереди к скрипту, прекращающему какие-либо действия, далее позволяет выполняться следующему потоку, стоящему в очереди.
-Если скрипт вызывает другую функцию во внешнем скрипте, или вызывает "скрытую"(англ. latent) функцию (функция, которая совершает на себе какое-то действие перед возвратом), it lets in the next thing from the cue while the other thread is off doing that other thing. Затем, когда новый поток работает со скриптом, when the previous thread that was off doing it's thing wants to come back and continue processing, теперь он должен стоять в очереди, пока новый поток выполняется с помощью скрипта (или вызывает скрытую функцию или функцию из другого скрипта)
+Если скрипт вызывает другую функцию во внешнем скрипте, или вызывает "латентную"(англ. latent) функцию (функция, которая совершает на себе какое-то действие перед возвратом), it lets in the next thing from the cue while the other thread is off doing that other thing. Затем, когда новый поток работает со скриптом, when the previous thread that was off doing it's thing wants to come back and continue processing, теперь он должен стоять в очереди, пока новый поток выполняется с помощью скрипта (или вызывает латентную функцию или функцию из другого скрипта)
 Вы можете спросить себя, почему это необходимо. Проще говоря, то самое, что делает многопоточную программу красивой также является и источником всех её проблем - одновременное выполнение каких-то действий. Два потока могут выполнять один и тот же набор инструкций, в одно и то же время. Они могут считывать значение в одно и то же время и самостоятельно обработать его, а затем записать обратно в память. Пока они используют '''одни и те же данные''' в '''одно и то же время''', выполняя '''одни и те же операции''' в потоке, можно сделать простой вывод, что результат этих операций будет одинаковым, и что результат будет сохранен обратно в память дважды, делая работу других потоков избыточной и не верной. Вы никогда не хотите иметь два конкурирующих потока - кто из них будет записывать значение в память первым или даже считывать фрагмент данных, в одно и то же время, потому что это зачастую выполнение одних и тех же операций дважды (because of the dependence on the initial conditions of the data while reading will affect all subsequent operations on that data or any other that is affected by it). Something is needed to prevent this from happening, a form of mutual exclusion. A thread gains the edge, invokes a lock and all other threads must wait for the "lucky" thread to say: "I'm done." and release the lock. Usually, a queue forms (FIFO structure, first in, first out, logical) of all the threads that have been coming in the meantime and patiently waiting. And then the second thread engages the lock and does its thing. This is an effective way for instructions to operate properly on good, valid data - without racing around.
@@ Строка 124: / Строка 124: @@
 </syntaxhighlight>
-Свойство myProperty гарантированно будет равно 5 когда вызывается “какое-либо действие”. Если же под “каким-либо действием” используется скрытая функция, или вызывается функция не из вашего скрипта или из родительского, то свойство myProperty может измениться.
+Свойство myProperty гарантированно будет равно 5 когда вызывается “какое-либо действие”. Если же под “каким-либо действием” используется латентная функция, или вызывается функция не из вашего скрипта или из родительского, то свойство myProperty может измениться.
 <syntaxhighlight lang="papyrus">
@@ Строка 140: / Строка 140: @@
 </syntaxhighlight>
-SetStage это скрытая функци, поэтому значение myPropery может измениться, даже если вы просто используете “SetStage(10)” и ваш скрипт расширяется скриптом Quest и прикреплен к квесту.
+SetStage это латентная функция, поэтому значение myPropery может измениться, даже если вы просто используете “SetStage(10)” и ваш скрипт расширяется скриптом Quest и прикреплен к квесту.
 В случае с фрагментом – вполне вероятно, что свойство myProperty больше не будет равно 5, в то время как запущен этот фрагмент. Запомните: вы вызываете setStage, НЕ функцию. Fragments execute “some time in the future” (which happens to be very soon in most cases). This is one case where a function call is much more useful than a fragment.

@@ Строка 150: / Строка 150: @@
 == Смотрите так же ==
-*[[:Категория:Скрытые Функции]]
+*[[:Категория:Латентные функции]]
 [[Category:Papyrus]]

← Предыдущая		Версия 19:57, 23 апреля 2012
Строка 1:		Строка 1:
		+	[[Файл:Symbol_error.png]] '''Статья не закончена!'''
		+	[[Category:Незаконченная статья]]
		+
	Papyrus это '''поточный'''(англ. threaded) скриптовой язык. По сути, это означает, что игра может работать с несколькими скриптами в параллельном режиме. Это позволяет Creation Engine более эффективно управлять обработкой скриптов. Скриптеры Papyrus должны по меньшей мере бегло понимать, что написано в этой, специально созданной для них ветке.		Papyrus это '''поточный'''(англ. threaded) скриптовой язык. По сути, это означает, что игра может работать с несколькими скриптами в параллельном режиме. Это позволяет Creation Engine более эффективно управлять обработкой скриптов. Скриптеры Papyrus должны по меньшей мере бегло понимать, что написано в этой, специально созданной для них ветке.

@@ Строка 103: / Строка 103: @@
   Если вызывать функцию IncrementMyProperty из внешнего скрипта множество раз подряд, будет ли это "безопасным потоком"?
-...'''assuming that all functions and the property itself are in the same script.'''
+...'''при условии, что все функции и само свойство находятся в том же скрипте.'''
 <syntaxhighlight lang="papyrus">
 Function IncrementMyProperty
@@ Строка 110: / Строка 110: @@
 </syntaxhighlight>
-% “thread safe”. myProperty will correctly increment. Right now it resolves to two function calls and as far as you should ever know, will always resolve that way.
+% “безопасный поток”. myProperty будет правильно увеличиваться. Сейчас она выполняет два вызова функции, и, до какого-то количества раз, вы всегда должны знать сколько раз нужно вызывать эту функцию, если решаете свою задачу этим путем.
 <syntaxhighlight lang="papyrus">
@@ Строка 116: / Строка 116: @@
    myProperty += 1
       if myProperty == 5
-         ;do something
+         ;какое-либо действие
       endif
 endFunction
 </syntaxhighlight>
-myProperty is guaranteed to be 5 when “do something” executes. If “do something” goes latent, or calls a function outside your script or its parents, myProperty may change.
+Свойство myProperty гарантированно будет равно 5 когда вызывается “какое-либо действие”. Если же под “каким-либо действием” используется скрытая функция, или вызывается функция не из вашего скрипта или из родительского, то свойство myProperty может измениться.
 <syntaxhighlight lang="papyrus">
@@ Строка 131: / Строка 131: @@
 endFunction
-;Elsewhere In MyQuest’s stage 10 fragment:
+;Где-то в другом месте, где этам MyQuest равен 10 фрагмент:
 If myProperty == 5
-   ;do something
+   ;какое-либо действие
 endif
 </syntaxhighlight>
-SetStage is Latent, therefore myPropery may change, even if you just use “SetStage(10)” and your script extends Quest and is attached to the quest.
+SetStage это скрытая функци, поэтому значение myPropery может измениться, даже если вы просто используете “SetStage(10)” и ваш скрипт расширяется скриптом Quest и прикреплен к квесту.
-In the case of the fragment – it is entirely likely that myProperty will no longer equal 5 by the time the fragment runs. Remember: you called setStage, NOT a function. Fragments execute “some time in the future” (which happens to be very soon in most cases). This is one case where a function call is much more useful than a fragment.
+В случае с фрагментом – вполне вероятно, что свойство myProperty больше не будет равно 5, в то время как запущен этот фрагмент. Запомните: вы вызываете setStage, НЕ функцию. Fragments execute “some time in the future” (which happens to be very soon in most cases). This is one case where a function call is much more useful than a fragment.
-Please note:
+Пожалуйста, возьмите на заметку:
-'''If myProperty is NOT in your local script, then “myProperty += 1” may not increment.''' This is because it resolves to “myProperty.set(myProperty.get() + 1)”, and myProperty’s value may change between the get and set calls since it isn’t on your own script. [Editor's note: Which is why you would write a IncrementMyProperty() function in that other script -- JPD ]
+'''Если свойство myProperty находится НЕ в вашем скрипте, то “myProperty += 1” может не увеличить значение этого свойство.''' Это потому что it resolves to “myProperty.set(myProperty.get() + 1)”, и значение myProperty может меняться между the get and set calls since it isn’t on your own script. [Editor's note: Which is why you would write a IncrementMyProperty() function in that other script -- JPD ]
--Jeff
+''-Jeff''
 == Смотрите так же ==

@@ Строка 100: / Строка 100: @@
 == Другой пример ==
-From an email to Jeff asking if calling IncrementMyProperty from an external script multiple times in a row was "thread safe."
+Из электронного сообщения от Jeff'а
 ...'''assuming that all functions and the property itself are in the same script.'''
@@ Строка 143: / Строка 144: @@
 '''If myProperty is NOT in your local script, then “myProperty += 1” may not increment.''' This is because it resolves to “myProperty.set(myProperty.get() + 1)”, and myProperty’s value may change between the get and set calls since it isn’t on your own script. [Editor's note: Which is why you would write a IncrementMyProperty() function in that other script -- JPD ]
 -Jeff
 == Смотрите так же ==

@@ Строка 85: / Строка 85: @@
 === Примечание о прослеживании "GoToState()" ===
-В предыдущем примере, обратите внимание, где вызывается функция goToState(). Зачем? Потому, что функция additem() является внешним скриптом (как и setValue() в примере ниже), она создает возможность для другого потока, чтобы начать обработку этого скрита, прежде чем вы перейдете к нужному вам состоянию. Поэтому сначала перейдите к желаемому. Your thread will complete the instructions below the gotoState() call just fine, and future threads will treat the script as being in the state - "XYZ" in the example below - when they encounter it.
+В предыдущем примере, обратите внимание, где вызывается функция goToState(). Зачем? Потому, что функция additem() является внешним скриптом (как и setValue() в примере ниже), она создает возможность для другого потока, чтобы начать обработку этого скрита, прежде чем вы перейдете к нужному вам состоянию. Поэтому сначала перейдите к желаемому. Ваш поток выполнит инструкции ниже вызова функции gotoState() что замечательно, и будущие потоки будут рассматривать скрипт, уже имея нужное состояние - "XYZ" в примере ниже - когда они столкнуться с ним.
 Другими словами - НЕ делайте такого:

@@ Строка 39: / Строка 39: @@
 == Поточность: Базовый Пример ==
-На картинке ниже, игрок активирует рычаг. Так как это хороший игрок, согласующий свои действия, он активирует его всего один раз. Игра передаст Papyrus уведомление о событии - активации. Так как наш скрипт содержит Событие '''onActivate()''', игра создаст '''"Поток"''', который можно рассматривать как набор инструкций, скопированный с нашего скрипта. Игра поместит его в очередь для выполнения, и немедленно приступит к его обработке.
+На картинке ниже, игрок активирует рычаг. Так как это хороший игрок, продумывающий свои действия, он активирует его всего один раз. Игра передаст Papyrus уведомление о событии - активации. Так как наш скрипт содержит Событие '''onActivate()''', игра создаст '''"Поток"''', который можно рассматривать как набор инструкций, скопированный с нашего скрипта. Игра поместит его в очередь для выполнения, и немедленно приступит к его обработке.
 [[Файл:Threads01.jpg|700px]]
-Очень скоро - вероятно, в следующем кадре - игра обрабатывает поток. Давайте представим, что содержимое нашего события onActivate() выглядит как-то так:
+Очень скоро - вероятно, в следующем кадре - игра обрабатывает этот поток. Давайте представим, что содержимое нашего события onActivate() выглядит как-то так:
 <syntaxhighlight lang="papyrus">
 ; Примечание - это не функциональный фрагмент

@@ Строка 11: / Строка 11: @@
 Если скрипт вызывает другую функцию во внешнем скрипте, или вызывает "скрытую"(англ. latent) функцию (функция, которая совершает на себе какое-то действие перед возвратом), it lets in the next thing from the cue while the other thread is off doing that other thing. Затем, когда новый поток работает со скриптом, when the previous thread that was off doing it's thing wants to come back and continue processing, теперь он должен стоять в очереди, пока новый поток выполняется с помощью скрипта (или вызывает скрытую функцию или функцию из другого скрипта)
-Вы можете спросить себя, почему это необходимо. Проще говоря, то самое, что делает многопоточную программу красивой также является и источником всех её проблем - одновременное выполнение каких-то действий. Два потока могут выполнять один и тот же набор инструкций, в одно и то же время. Они могут считывать значение в одно и то же время и самостоятельно обработать его, а затем записать обратно в память. Пока они используют '''одни и те же данные''' в '''одно и то же время''', выполняя '''одни и те же операции''' на нем(потоке), можно сделать простой вывод, что результат этих операций будет одинаковым, и что результат будет сохранен обратно в память дважды, делая работу других потоков избыточной и не верной. Вы никогда не хотите иметь два конкурирующих потока - кто из них будет записывать значение в память первым или даже считывать фрагмент данных, в одно и то же время, потому что это зачастую выполнение одних и тех же операций дважды (because of the dependence on the initial conditions of the data while reading will affect all subsequent operations on that data or any other that is affected by it). Something is needed to prevent this from happening, a form of mutual exclusion. A thread gains the edge, invokes a lock and all other threads must wait for the "lucky" thread to say: "I'm done." and release the lock. Usually, a queue forms (FIFO structure, first in, first out, logical) of all the threads that have been coming in the meantime and patiently waiting. And then the second thread engages the lock and does its thing. This is an effective way for instructions to operate properly on good, valid data - without racing around.
+Вы можете спросить себя, почему это необходимо. Проще говоря, то самое, что делает многопоточную программу красивой также является и источником всех её проблем - одновременное выполнение каких-то действий. Два потока могут выполнять один и тот же набор инструкций, в одно и то же время. Они могут считывать значение в одно и то же время и самостоятельно обработать его, а затем записать обратно в память. Пока они используют '''одни и те же данные''' в '''одно и то же время''', выполняя '''одни и те же операции''' в потоке, можно сделать простой вывод, что результат этих операций будет одинаковым, и что результат будет сохранен обратно в память дважды, делая работу других потоков избыточной и не верной. Вы никогда не хотите иметь два конкурирующих потока - кто из них будет записывать значение в память первым или даже считывать фрагмент данных, в одно и то же время, потому что это зачастую выполнение одних и тех же операций дважды (because of the dependence on the initial conditions of the data while reading will affect all subsequent operations on that data or any other that is affected by it). Something is needed to prevent this from happening, a form of mutual exclusion. A thread gains the edge, invokes a lock and all other threads must wait for the "lucky" thread to say: "I'm done." and release the lock. Usually, a queue forms (FIFO structure, first in, first out, logical) of all the threads that have been coming in the meantime and patiently waiting. And then the second thread engages the lock and does its thing. This is an effective way for instructions to operate properly on good, valid data - without racing around.
 The same concept is employed with Papyrus scripts, but scripts as a whole. As soon as an object activates something that possibly modifies data in the script, everyone else must queue and wait patiently until it has been cleared to proceed with that specific script. If another script is invoked, it doesn't directly clash with data of other running scripts, it is free to run asynchronously. Locks are just necessary in places where it needs to be made sure that the data is intact and valid, synchronized. When two objects want to operate on a third object, a race ensues. Which is killed by synchronization, allowing awesomeness to continue.

@@ Строка 7: / Строка 7: @@
 Только одна вещь одновременно может взаимодействовать со скриптом.
-Если же несколько вещей (потоков) пытаются одновременно управлять скриптом, a "queue" forms of all the threads which essentially wait in line for the script to stop doing something, then it lets the next thread in line in.
+Если же несколько вещей(потоков) пытаются одновременно управлять скриптом, то они выстраиваются в форме "очереди"(англ. queue), состоящей из всех этих потоков, которые по существу ждут очереди к скрипту, прекращающему какие-либо действия, далее позволяет выполняться следующему потоку, стоящему в очереди.
 Если скрипт вызывает другую функцию во внешнем скрипте, или вызывает "скрытую"(англ. latent) функцию (функция, которая совершает на себе какое-то действие перед возвратом), it lets in the next thing from the cue while the other thread is off doing that other thing. Then while the new thread is occupying the script, when the previous thread that was off doing it's thing wants to come back and continue processing, now it has to wait in line until the new thread is done with the script (or it calls a latent function or function on another script)