Hi, i have multithreaded gui Lazarus application (socket server), that thread call the gui function (open file), i used Synchronize for that read with function ShowFile
It is work fine with Windows, but in Linux (OpenSuse 11) the procedure ShowFile not called.

I used in the main project file
  {$IFDEF UNIX}
  cthreads,
  {$ENDIF}

Did i missed somthing?

my procedure called like that
Connection.Synchronize(ShowFile);

Connection is a thread, and this line called inside a object created and processed inside that thread, ShowFile must open a file in my gui editor.

Thanks in advance.

Sounds correct.
Without more code it is hard to help more.

This might help:
http://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial

Mattias

The code responsible for "Synchronize" is done in the "Widget Type" (aka "interfaces") in the LCL.

Not all Widget Types support "Synchronize" and there are versions of the LCL with broken support.

I just tested that with the most recent LCL version of the GTK2 Widget set, "synchronize" seems to work fine.

-Michael

Michael Schnell wrote

.. the most recent LCL version

in the svn.

-Michael

But for how long? I had a lot of trouble with a program a few months ago where data was being fetched from an SQL database in a thread, and was being drawn on a visible form and driving debug output to a TMemo via synchronise. If, and only if, the TMemo was visible then the program would lock up after about 280 iterations; however, I've not managed to characterise that well enough to dare raising it as a bug.

Mark Morgan Lloyd wrote

But for how long?

The svn version of GTK2 is working since a few weeks. I can't comment on "official" distributions or different Widget Types.

-Michael

No, I mean how long has anybody run each test program. I had a situation that was reproducible in the context of my code, although I didn't get to the point of refining it to a particular mix of components and "glue" logic.

Mark Morgan Lloyd wrote

how long has anybody run each test program.

The known problem with synchronize is that the event only is acknowledged when some GUI event occurs, too.

I am not aware of any long-time running problems.

-Michael

Yes, I hit that one very quickly so added a live time display at the bottom of the debugging window.

I am not aware of any long-time running problems. -Michael

I resolved my problem with not use the thread object outside the thread when the Synchronize call this method, i do not know if it that the real reason, but my project now working in Linux.

you can see the this lines in my changes in
https://github.com/parmaja/miniedit/commit/787112191f1e3fd260b541a523050a150388eaf2#L4L448

-procedure TdbgpGetCurrent.ShowFile; //this function must synced
+procedure TdbgpGetCurrent.ShowFile; //this function must Synchronize
 begin
-  Connection.Server.ShowFile(Connection, FFileName, FLine);
+  DBGP.ShowFile(FCurKey, FCurFile, FCurLine);
 end;

Thanks

Zaher Dirkey wrote

procedure TdbgpGetCurrent.ShowFile; //this function must synced

If the only purpose of the function really is showing something, maybe Application.QueuAsyncCall might be a better alternative, as the thread can go on running while the showing is performed. Of course here it might be necessary that the stuff to be shown is copied and provided via the parameter of QueuAsyncCall, if it's possible that the thread inconstantly modifies it in between.

-Michael

Mattias Gaertner ha scritto:

I have a question related to this subject. Working with Borland's stuff (Kylix) I stumbled into a problem, and I'd like to know if the same applies also to Lazarus.

I had a multithread application with a thread which receives data through a communication line. I thought it safe to use a TStringList, which AFAIK is not a visual object. The main thread would create the StringList, the other thread would append strings to the list, and when it was done, the main thread would perform the required processing. The logic of the application itself made it sure that there was no conflict whatsoever. It turned out that it didn't work at all, silently filling with garbage the List, and I was forced to move all code related to the StringList in the main thread, with a slight overhead which, IMO should not have been necessary. I couldn't understand if it was a Kylix bug or a feature.

How would Lazarus behave with respect to this scenario? The scheme I described is expected to work?

Giuliano

Correct.

Ok. This should work if you use TThread to create the thread.

Without more code I can only give the above link again.

Mattias

No. You should use a TMultiReadExclusiveWriteSynchronizer object to synchronize access to your object, or use a critical section.

Michael.

Ehm, he made sure that only one thread accesses the TStringList at a time.
Why should TMultiReadExclusiveWriteSynchronizer be necessary?

Mattias

To me, this is not obvious from his mail ?

If the main thread only starts work after the secondary thread is done, there should be no problem.

Michael.

2011/5/25 :

I thought it was obvious from:
"The logic of the application itself made it sure that there was no conflict whatsoever. "

But maybe that was not not what Giuliano meant by "no conflict".

If the main thread only starts work after the secondary thread is done, there should be no problem.

Vincent

This is what was not clear to me...

If no conflict can mean 'it adds only', then there is a conflict at a lower level, because adding can mean a reallocation of the array of strings.

Michael.

ha scritto:

The full picture is:
1) The main thread creates the String List, and doesn't touch it any more.
2) The other thread is activated and it is the only one which appends strings to the list.
3) When the other thread is terminated, the main thread processes the list.

I would expect that whatever activity occurs as an effect of appending strings (such as reallocating the array) would occur in the context of the thread performing the action, that all pertinent information is stored in fields of the object itself, and that the main thread is never involved. Am I wrong on this aspect?

Giuliano

No, you are right. If it is designed as described above, then it should work.

Michael.

ha scritto:

Thank you. With Kylix it didn't work, but there was no mailing list to ask :'( .
Now I'm going to develop something similar with Lazarus, and I felt it wise to ask, before bumping my head again against a brick wall.

Giuliano

But that mean he have only one thread worked at same time.

Giuliano Colla wrote

Thank you. With Kylix it didn't work, but there was no mailing list to ask :'( . Now I'm going to develop something similar with Lazarus, and I felt it wise to ask, before bumping my head again against a brick wall.

I was also a Kylix 3 user. I can confidently say that the Free Pascal Compiler and Lazarus IDE has long since surpassed Kylix 3 features and functionality.

I'd say let the old boy rest, and use FPC instead. :)

Regards,
- Graeme -

Giuliano Colla wrote

The main thread would create the StringList, the other thread would append strings to the list,

AFAIK you need to protect the concurrent access to a StringList by a CritcalSection.

-Michael

2 threads:
The main thread takes care of the GUI (keeps the application responsive), while the second thread collects data, and notifies the main thread when it is done. The main thread then updates the GUI with the available data.

A simple scheme. I often do it like this.

Michael.

As said, it should work with FPC.

But more importantly, it should also work with Kylix. Maybe you do something detail wrong (e.g. start processing in the mainthtread after sending terminate to the thread, but not waitfor it)

Graeme Geldenhuys ha scritto:

I'd gladly follow your advice, but we have greedy customers which, once they've bought a 500,000$ machinery, they want it to be supported for 10 years or so, instead of throwing it in the waste bin each other year, and buying a new one! ;-)

Giuliano

Zaher Dirkey ha scritto:

There's quite a number of other activities going on, which I didn't describe, because they were not relevant in this context. If what I described had been the only task to perform, then multithreading would be unnecessary.

Giuliano