mORMot Open Source

LoPiTaL

Member

Registered: 2013-01-04

Posts: 30

mutlithread and sicPerUser variables

Hi everyone!
I have a doubt about handling multithreads, lets see:

I have defined an interface-based service with sicPerUser mode.
The class implementing this service contains a variable of a class inheriting from TSQLRecord for cache purposes.
This service has two methods, one to update (it just assigns several RawUTF8s from the incoming record to that variable) and one to retrieve the information from that variable.

My doubt is, is this a correct way to handle this? Or should I use critical sections when updating / retrieving the data? Or should I use a completely different aproach?

I post also a bit of the code of the update procedure:

  FInformation.Name:=FRecord.FName;
  FInformation.NickName:=FRecord.FNickName;
  FInformation.BirthDate:=FRecord.FBirthDate;
  FInformation.EMail:=FRecord.FEmail;

where all the vars are RawUTF8 but the BirthDate, which is TDateTime.

The retrieving procedure is similar but reversed (FRecord.FName:=FINformation.Name; ....).

Best regards,
LoPiTaL

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,661

Website

Re: mutlithread and sicPerUser variables

In the SAD 1.18 pdf, you have clear explanations:

Note also that all those life-time modes expect the method implementation code to be thread-safe and reintrant on the server side - only exceptions are sicSingle mode, which will have its own running instance, and sicPerThread, which will have its methods always run in the same thread context. In practice, the same user can open more than one connection, therefore it is recommended to protect all implementation class method process, or force the execution in the main thread with opt*InMainThread options.

That is, in sicPerUSer mode, all method code has to be reentrant, unless you specify the optExecInMainThread option for all the methods of the interface.
But execution in the main thread may reduce the benefit of multi-threading.

Or, you have to use critical sections to protect concurrent access.

See also "Thread safety" paragraph in the SAD, and generally, RTFM search for "thread-safe" in the document index, at its beginning!