On 09/17/2014 04:51 PM, Xiangrong Fang wrote:
2014-09-17 16:09 GMT+08:00 Michael Schnell <mschn...@lumino.de
<mailto:mschn...@lumino.de>>:
Here you are.
It is strange that it works on one computer but does not work (or
partially work) on another -- causing SIGSEGV. Both running same
environment - Ubuntu 14.04 x86_64 fpc 2.6.4 laz1.2.4.
That in fact is strange.
Of course here (Linux x86_32, newest svn version of fpc and Lazarus) it
does work, otherwise I would not have posted it.
Did you try the unmodified project ?
I don't understand how the critical section works.
TCriticalSection is a straight forward semaphore. (->
https://en.wikipedia.org/wiki/Semaphore_%28programming%29 )
Of course there are several kinds of semaphores out there:
- binary and counting: TCriticalSection is binary
- blocking or not blocking when a Thread/Task tries to take it while
it already holds it: TCriticalSection does not block
- allowing or disallowing a Thread/Task to free it even though it is
helt by another Thread/Task: TCriticalSection disallows this.
I try to write a test program, which does the following:
The main thread create a predefined number of threads, which start
running on creation. The thread's wait for a critical section
variable, when acquired, try to crack a given integer, see if it is
prime number or not, report back to main thread about the result and
get the next number to crack from main thread. The main thread output
crack result of every thread in a memo box.
Are you sure that only the main thread does anything related to the GUI
? This is strictly forbidden for worker threads and results in SIGSEGV.
This is why TThreadPool offers events OnReady events that are run in the
main thread. ("synchronized").
I simply don't know how to coordinate the threads. And got many
strange errors like
Semaphore init failed (maybe too many running threads)?
I never saw such an error. Anyway, I suppose you will do multithreading
just for sake of performance. Here running more threads than
CPUs/Hardware Threads does not make sense, as it will slow down the
calculation due to unnecessary time slice related task switches which
result in local cache misses (Linux tries to keep a thread on the same
CPU if possible, but this is only possible when there are not much more
active threads than CPUs). So there will never be "too many" threads.
In any case start with simple stuff (e.g. using my example and replacing
the "Tasks" with first simple and then more complex "Execute" procedures.
something wrong in raise.c, laz asked me if I want to locate myself,
blahblah.
I have no idea what "raise.c" is supposed to be.
May I send you my source, or you can write a demo for me? Thanks a lot!
I already did provide you with a demo. I can enhance this for you if you
have a certain request.
-Michael
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
