Translate

In the above example we assign a ring of numbers to a variable `a` and then used it within two separate `live_loop`s. In the first live loop every `0.5`s we sort the ring (to `(ring 1, 2, 3, 4, 5, 6)`) and then print it out to the log. If you run the code, you'll find that the printed list *is not always sorted!*. This may surprise you - especially that sometimes the list is printed as sorted, and sometimes it is not. This is called non-deterministic behaviour and is the result of a rather nasty problem called a race-condition. The problem is due to the fact that the second live loop is also manipulating the list (in this case shuffling it) and by the time the list is printed, sometimes it has just been sorted and sometimes it has just been shuffled. Both live loops are racing to do something different to the same variable and every time round a different loop 'wins'.
SourceTranslationState
639
s = play 50, release: 8
sleep 2
control s, note: 62
s = play 50, release: 8
sleep 2
control s, note: 62
640
We'll look into controlling synths in more detail in a later section.
Veremos como controlar os synths em mais detalhe numa secção posterior.
641
Warning: Variables and Threads
Aviso: Variáveis and Threads
642
Whilst variables are great for giving things names and capturing the results of things, it is important to know that they should typically only be used locally within a thread. For example, *don't do this*:
Embora as variáveis sejam ótimas para dar nomes às coisas e capturar os resultados das coisas, é importante saber que elas normalmente só devem ser usadas localmente em um segmento. Por exemplo, *não faça isso*:
643
a = (ring 6, 5, 4, 3, 2, 1)
live_loop :shuffled do
a = a.shuffle
sleep 0.5
end
live_loop :sorted do
a = a.sort
sleep 0.5
puts "sorted: ", a
end
a = (ring 6, 5, 4, 3, 2, 1)
live_loop :shuffled do
a = a.shuffle
sleep 0.5
end
live_loop :sorted do
a = a.sort
sleep 0.5
puts "sorted: ", a
end
644
In the above example we assign a ring of numbers to a variable `a` and then used it within two separate `live_loop`s. In the first live loop every `0.5`s we sort the ring (to `(ring 1, 2, 3, 4, 5, 6)`) and then print it out to the log. If you run the code, you'll find that the printed list *is not always sorted!*. This may surprise you - especially that sometimes the list is printed as sorted, and sometimes it is not. This is called non-deterministic behaviour and is the result of a rather nasty problem called a race-condition. The problem is due to the fact that the second live loop is also manipulating the list (in this case shuffling it) and by the time the list is printed, sometimes it has just been sorted and sometimes it has just been shuffled. Both live loops are racing to do something different to the same variable and every time round a different loop 'wins'.
645
There are two solutions to this. Firstly, *don't use the same variable in multiple live loops or threads*. For example, the following code will always print a sorted list as each live loop has its own separate variable:
646
live_loop :shuffled do
a = (ring 6, 5, 4, 3, 2, 1)
a = a.shuffle
sleep 0.5
end
live_loop :sorted do
a = (ring 6, 5, 4, 3, 2, 1)
a = a.sort
sleep 0.5
puts "sorted: ", a
end
647
However, sometimes we do want to share things across threads. For example, the current key, BPM, synth etc. In these cases, the solution is to use Sonic Pi's special thread-safe state system via the fns `get` and `set`. This is discussed later on in section 10.
648
5.7 Thread Synchronisation
5.7 Sincronização de Threads
649
Thread Synchronisation
Sincronização de Threads
7 months ago anonymous has suggested
No exemplo acima, atribuímos um anel de números a uma variável 'a' e depois o usamos dentro de dois live_loop`s separados. No primeiro loop ao vivo a cada 0.5 nós classificamos o anel (para `(anel 1, 2, 3, 4, 5, 6)`) e então o imprimimos no log. Se você executar o código, verá que a lista impressa * nem sempre é classificada! *. Isso pode surpreendê-lo - especialmente porque às vezes a lista é impressa como ordenada e às vezes não é. Isso é chamado de comportamento não determinístico e é o resultado de um problema bastante desagradável chamado de condição de corrida. O problema se deve ao fato de que o segundo loop ao vivo também está manipulando a lista (neste caso, embaralhando-a) e no momento em que a lista é impressa, às vezes ela acaba de ser ordenada e algumas vezes acaba de ser embaralhada. Ambos os loops ao vivo estão correndo para fazer algo diferente para a mesma variável e toda vez que um loop diferente 'ganha'.

Suggested change:

No exemplo acima, atribuímos um anel de números a uma variável 'a' e depois o usamos dentro de dois live_loop`s separados. No primeiro loop ao vivo a cada 0.5 nós classificamos o anel (para `(anel 1, 2, 3, 4, 5, 6)`) e então o imprimimos no log. Se você executar o código, verá que a lista impressa * nem sempre é classificada! *. Isso pode surpreendê-lo - especialmente porque às vezes a lista é impressa como ordenada e às vezes não é. Isso é chamado de comportamento não determinístico e é o resultado de um problema bastante desagradável chamado de condição de corrida. O problema se deve ao fato de que o segundo loop ao vivo também está manipulando a lista (neste caso, embaralhando-a) e no momento em que a lista é impressa, às vezes ela acaba de ser ordenada e algumas vezes acaba de ser embaralhada. Ambos os loops ao vivo estão correndo para fazer algo diferente para a mesma variável e toda vez que um loop diferente 'ganha'.

Loading…

Loading…

Things to check

Glossary

Source Translation
loop loop

Source information

Source string location
05.6-Variables.md:154
Source string age
a year ago
Translation file
etc/doc/lang/sonic-pi-tutorial-pt.po, string 644
String priority
Medium