Forums > Jitter

writing on a matrix: isn't it an atomic operation??

July 27, 2007 | 12:08 pm

Hi,

I attach a simple patch where I sometimes get a behaviour I can’t explain.

I (think I) make sure to do things in a certain order and it seems that they sometimes happen in reversed order, so I can’t understand what I am doing wrong.

Please look at the attached patch: expected vs observed behaviour is detailed in the comments inside the patch, and the patch is extremely simplified.

The only explanation I can find is that when you send a message to a matrix (such as the output of another matrix, or a setall message) that is supposed to perform a write operation on that matrix, it is not guaranteed that this operation is atomically performed before any other message arrives to the same matrix. That is, if a second message arrives after the first one (obviously in the order of milliseconds after or less), the write operation of the second message MAY be performed before the write operation triggered by the first message.

It seems to me that it shouldn’t be so… but that’s what I am observing…..

Can anyone confirm my analysis? Or point out what’s wrong in the patch?

In case this is correct, is there a way of ensuring "atomicity" of operations in the sense explained above (and in the patch)?

I can program in such a way to always ensure that max events (i.e. bangs, messages etc) are delivered in the order I need them to be delivered, but if I cannot trust that the operations they perform are then executed in the same order, well, programming is gonna become quite complicated ;)
If it is so, I’m sure a lot of people must have faced this "problem" and can suggest frameworks and techniques to make things easier.

Note that in the attached example, I may easily re-draw the black square at every frame when the big toggle is off, but I want to avoid unnecessary cpu-consuming operations such as keep refreshing matrix data that I know is not changing.

Thanks in advance
bye
matteo sisti sette


July 27, 2007 | 3:20 pm

Hello Matteo,
If you are going to attach patches to the forums, please either paste it
as text or create a .zip archive. The current binary format of max
patches almost always gets corrupted in transfers.

Please also take a minute to read this page:

http://cycling74.com/twiki/bin/view/FAQs/BeginnersFAQ

Cheers,
Andrew B.


July 27, 2007 | 4:42 pm

Sorry.

Here’s the same patch attached as a zip file


July 28, 2007 | 1:46 am

Adding a deferlow before the 1 X 1 matrix makes it reliable, as does using a
qmetro as the METROBANG driver. I run into this sort of problem many times.

Christopher Overstreet

On 7/27/07 5:08 AM, "matteo sisti sette" wrote:

> Hi,
>
> I attach a simple patch where I sometimes get a behaviour I can’t explain.
>
> I (think I) make sure to do things in a certain order and it seems that they
> sometimes happen in reversed order, so I can’t understand what I am doing
> wrong.
>
> Please look at the attached patch: expected vs observed behaviour is detailed
> in the comments inside the patch, and the patch is extremely simplified.
>
> The only explanation I can find is that when you send a message to a matrix
> (such as the output of another matrix, or a setall message) that is supposed
> to perform a write operation on that matrix, it is not guaranteed that this
> operation is atomically performed before any other message arrives to the same
> matrix. That is, if a second message arrives after the first one (obviously in
> the order of milliseconds after or less), the write operation of the second
> message MAY be performed before the write operation triggered by the first
> message.
>
> It seems to me that it shouldn’t be so… but that’s what I am observing…..
>
> Can anyone confirm my analysis? Or point out what’s wrong in the patch?
>
> In case this is correct, is there a way of ensuring "atomicity" of operations
> in the sense explained above (and in the patch)?
>
> I can program in such a way to always ensure that max events (i.e. bangs,
> messages etc) are delivered in the order I need them to be delivered, but if I
> cannot trust that the operations they perform are then executed in the same
> order, well, programming is gonna become quite complicated ;)
> If it is so, I’m sure a lot of people must have faced this "problem" and can
> suggest frameworks and techniques to make things easier.
>
>
> Note that in the attached example, I may easily re-draw the black square at
> every frame when the big toggle is off, but I want to avoid unnecessary
> cpu-consuming operations such as keep refreshing matrix data that I know is
> not changing.
>
>
> Thanks in advance
> bye
> matteo sisti sette


July 30, 2007 | 9:57 am

Thank you for the suggestion.

May you please explain me a little more how this trick works?
(I understand how to do it, but I’m confused about why it fixes the problem)

I have read the help about qmetro, deferlow, jit.qball but I am still a bit confused.

Thank you in advance
m.


July 30, 2007 | 10:00 am

By the way, your second suggested solution works, but the first one doesn’t.


July 30, 2007 | 10:42 am

I’ve understood a little more by reading "Event Priority in Max (scheduler vs queue) http://www.cycling74.com/story/2005/5/2/133649/9742

However, that article says that when "Overdrive" is not activated, there is no high priority thread at all.
So, since I have not enabled Overdrive (and I can see it is disabled), how is it possible that there is any difference between using metro and using qmetro??


Viewing 7 posts - 1 through 7 (of 7 total)