Significally faster notifications

Lately it’s been evident that the notification pusher isn’t fast enough. Every 60 seconds it is activated and sends out notifications to players who is in turn, has an invite, a new chat message etc. The problem is that each request to Google’s notification service takes about 0.5 seconds and it means that the capacity only is about 300 notifications per minute – not enough anymore during peak hours where there’s a need to send out more.

So I have now rewritten parts of RummiPusher to be multithreaded. This means that we now can do multiple requests at the same time. Initially we are using 5 threads which means that in the same time we could send one message before, we can now send five. The number of threads can easily be adjusted at needs but at the moment 5 is well enough to be able to send all notifications within the minute at hand.

Sometimes multiple threads is a blessing… sometimes it can be a real nightmare to code since multiple threads also means that two pieces of code sometimes want to access the same object at the same time, leading to uncertainty of what value this object should have.

A simple example is this. Assume that we have a simple multi threaded application where each thread wants to increase a counter by one. If that counter is 10 and is accessed by a thread, it turns to 11, right? Assume that two threads want to increase this value at the very same time. Then both of them “see” that the value is 10 and increase it by one. The result is that the counter is 11 when it should be 12.

This is called a “race condition” and should be avoided like the plague. In such a thing like RummiPusher this is not so serious. I mean, no one would lose their life if a notification is not sent. There’s another thing if this would happen in the app – which it has. Up until v1.38 of RummyFight there was a race condition during the re-play of other player’s melds if you are holding down FastForward. As you have seen there are a lot of tiles moving at the same time then (multiple threads) and at rare cases a tile could be misplaced or “forgotten” by the re-play routine due to the fact that it (sometimes) failed to access a tile if it tried to move it WHILE it was already being moved elsewhere.

But that was fixed in v1.38 and later versions so that’s nothing we need to worry about anymore but it shows the danger with multiple threads and I can tell you it’s a real bitch to debug since it is almost impossible to simulate the situations where this can happen.

Ah well, I do wish however that Apple could show some multi threading in their app approval process since it’s now been 7 days and they haven’t still even looked at RummyFight for iPhone.

1 Response to “Significally faster notifications”

  1. 1 Sarlac
    December 12, 2012 at 3:44 pm

    I LOVE this game (definitely best Rummy app on the market!) but since upgrading to the paid version (v 1.45) the notifications no longer work which they did on the free version. Is this a glitch at all?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: