Matrex 2.0: project integrity in a multi-user system

Now it is a long time the alpha version of Matrex 2.0 was published, but a beta is still not available. The reason is that the task to make the core objects (project, matrix, function...) thread safe is complex.

Until now Matrex was a single-user system. That does not guarantee against concurrency problems, but makes certainly things easier than on a multi-user system, like Matrex 2.0. In Matrex 2.0 a function or chart or presentation can potentially be changed by multiple users in the same time, which can lead to unpredictable results.

To avoid this, the work I'm doing now is to make the project object not only a repository of its items (matrices, functions...) but to give it the responsibility of its own integrity, and to this, the complete responsibility of adding, updating and deleting items.

In Matrex 2.0 the chart editor, for example, is not able to update a chart object directly. It tells the project how to change the chart object, and the project changes it, after it checked that the change is possible and does not break its own integrity: charts are dependent by matrices and it could be possible that the change involves adding a matrix to it that during the chart editing gets deleted by a different user; in this case the project rejects the update, the chart does not get change and the editor gets an error.

The project's methods are guarded, so that it is impossible to do incompatible changes in the same time. For example it is not possible to delete a matrix in the same time a chart is updated.

In other words the project in Matrex 2.0 looks a lot like an SQL server with transactions. The SQL server makes sure two SQL updates cannot take place on the same rows of a table in the same time and an SQL update (or a group of them) can be integrally rejected (rollback) if something goes wrong, leaving the database as it was.

A side effect of these changes is that, since everything is done through the project, the items become more or less read-only for the editors and the rest of the GUI, simplifying the system.

In terms of performance these changes should be in-influent. What is important for the system performance are not the items editing, but the matrices calculations that derive from it, which are much more complex and CPU consuming.

I'm now in the middle of the work of changing project, items, editors to make them work in this way. As soon as I am finished I will publish a beta.

About MacOSX

If you are not able to install Matrex 1.3.5 on MacOSX, please check the article about this topic.
You can download a more recent beta version of the SWT library for Cocoa here.
As soon as Eclipse 3.5 Galileo will be released, I will update the setup files to use the new SWT library, which will probably solve the problem.

Why should I use Matrex if Excel 2007 supports multithreading?

One of the peculiar features of Matrex has always been the fact that functions are executed in different threads.
Now Excel 2007 supports a similar feature, so one could think that there are less reasons to use Matrex instead of Excel.
But that's wrong: the multithreading capabilities offered by the two products are different.

Purposes

Excel

Multithreading has been added to Excel to use both the cores in the new double core processors (Intel Core Duo and AMD X2).

Matrex

Matrex has introduced multithreading before these processors became popular and the purposes are the following:

• Don't block the GUI during the function calculations
• Get immediately the results of some calculation without to wait for the whole project (worksheet) to be recalculated.
  
• Avoid that I/O dependent functions (formulas) block CPU intensive functions.

Sure, Matrex is also able to use both the cores of a double core processor, but that is only a side effect of its multithreading feature.

Implementation

Excel

I don't have details on the implementation, but that is what I think happens:

When you recalculate a sheet the first time, all the dependencies among cells of the sheet (formulas) are examined and based on this the sheet is divided in 2 parts (or 4 if you have 4 cores) .
Each part is calculated by a thread.

Matrex

Matrex uses a pool of threads. Each function is calculated by a thread of the pool.
In this way the whole Matrex internal engine is multithreaded.
Only the GUI runs as a single thread, with which the other threads need to synchronize when matrices, charts or presentations are displayed in the viewers.


Conclusions

Multithreading has been just added to Excel to use well the dual core processors, but it is not a main feature in Excel: a part of the fact that the calculation is divided in 2 or more threads, the system works as in the previous versions.

Matrex is instead built on threads. They are everywhere: functions, matrices, presentations, charts, timers and the GUI have to cope with them.