Difference between revisions of "Thread safety in Visual Prolog"

From wiki.visual-prolog.com

(category)
(category)
Line 34: Line 34:
 
An <vp>odbcConnection</vp>/<vp>odbcStatement</vp> is not thread safe, but different <vp>odbcConnection</vp>'s/<vp>odbcStatement</vp>'s can be accessed in parallel.
 
An <vp>odbcConnection</vp>/<vp>odbcStatement</vp> is not thread safe, but different <vp>odbcConnection</vp>'s/<vp>odbcStatement</vp>'s can be accessed in parallel.
  
[[Category:Tutorials]]
+
[[Category:Multi-threading]]
 +
[[Category:GUI]]
 +
[[Category:ODBC]]

Revision as of 11:06, 4 March 2016

Thread safe:

  • Access to fact variables
  • Access to single facts
  • Access to determ facts

Not thread safe:

  • Nondeterm facts
  • GUI
  • Streams
  • odbcConnection/odbcStatement

Nondeterm facts

Read access is thread safe, but only a single thread should update a nondeterm fact. Reading can be done while update takes place.

GUI

Windows GUI is not thread safe, only the thread that runs the message pump of a window should accees that window. In Visual Prolog all windows (except modal dialogs) belong to the thread that have executed the vpi::init call.

Synchronization back to the GUI thread can be done using window::postAction, because the posted action will be executed by the GUI thread.

Modal dialogs run their own message pump and they are therefore owned by the thread that displays them.

Streams

Streams are in general not thread safe, but specific streams can be.

From Visual Prolog 7.4 the thread on messageControls are thread safe. In a GUI application stdio will thus be thread safe while it is redirected to a messageControl/messageForm, but if it is redirected to some other stream it will "inherit" the thread safety from that stream.

ODBC

An odbcConnection/odbcStatement is not thread safe, but different odbcConnection's/odbcStatement's can be accessed in parallel.