Memvars and Multi Threading

[robert]

Hi folks,

We are currently working on the implementation of the Memvar support in the runtime.
One question that we have is what to do with memvars and multi threading.
For PRIVATE memvars things are kind of obvious: since privates are visible in a function/method and the functions/methods called from this function, this automatically means that each thread will have its own privates "stack", similar to how each thread has its own local variables.

For PUBLICS however we have a choice: either they are shared between threads or each new thread gets its own copy of the PUBLICS list.
At this moment we are considering to make the PUBLICs shared between threads, just like GLOBALs.
We will handle the locking in the runtime, so you should not have to worry about that.
And this is different for GLOBALs where you need to handle the locking yourself.

Does this make sense ?
Are we overlooking something?

Robert

PS We are trying to implement memvar support with minimal impact on performance. When you are not using them at all then you will not be 'punished' by this new feature. At this moment we want to support them in the VO , XBase++ and Harbour dialect only (so not for Vulcan and Core). We are considering to also add a special compiler option that has to be set to enable the memvar support.

[wriedmann]

Hi Robert,

IMHO publics should be common to all threads.

For sure I will be one of the the first to need them in my report evaluation engine.
And I need a possibility to set them programmatically with functions like "MemvarGet()" and "MemVarPut()", and a possibility to remove a Memvar with a call like "MemVarKill()" would be a nice thing.

Memvars are needed to be injected into an macro evaluation engine (this is the only place where I need them).

Wolfgang

[leon-ts]

Hi Robert,

Threads are part of the process and work in a single address space of this process. If a variable is accessible by reference, then all threads have access to its same address in memory. A memvar declared as PUBLIC is essentially a global variable (as far as I understand, this is an entry in the global table: key = value). Therefore, all process threads must refer to the shared table.

Best regards,
Leonid

[robert]

Leonid, Wolfgang,
Thanks for your input. You confirm what we were thinking, so publics will be shared between threads.

Btw this is different for some other globals settings in X#
- threads do not share workareas
- threads do not share global state such as SetDeleted() and SetExact().

New threads start with an empty workarea list and get a copy of the values from the main thread, so they cannot accidentally break the main thread when changing a setting.

Robert

[wriedmann]

Hi Robert,

thank you very much!

WorkAreas and global settings don't need to be shared.
But if I understand this correctly: a DBServer object cannot be passed to a thread because the underlying workarea is not shared.
But SQL connection objects can be shared because there internal variables are passed through. If it is a good idea to do this is another issue.
But threads are needed with WPF, and sometimes they have very strange drawbacks (for example you cannot use a data object maintained in another thread as data source for a datagrid).

Wolfgang

[robert]

Wolfgang,
You are right about DbServers and threads with the current implementation of the DbServer class where the DbServer is linked to the workarea through the workarea number
We could probably change that in the future if we would build the dbserver on top of the RDD object.
If you really have to send the data to another thread you would have to save it to an array or another collection and pass that collection around.

Robert