On 09/19/2014 03:48 PM, Michael Schnell wrote:
I can post this version of the TThreadPool class here, if you might
want to try it. I'd be very interested in knowing if the project works
correctly on your (64 bit) systems.
I set up a virtual Box with 64 Bit Debian, installed the released 64
On 09/18/2014 09:44 PM, Mark Morgan Lloyd wrote:
I suggest calling it a vector
Thanks a lot for the clarification (I am not a native English speaker).
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 09/18/2014 10:32 AM, Xiangrong Fang wrote:
I don't quite understand the logic or difference between critical section
and events.
Following your suggestion to use events (here meaning semahores) instead
of critical sections (here meaning mutexes) I tried to modify my code to
use TEvent
On 09/19/2014 12:23 PM, Michael Schnell wrote:
Following your suggestion to use events (here meaning semahores)
instead of critical sections (here meaning mutexes) I tried to modify
my code to use TEvent (as same is Delphi compatible - or at least it
does exist in Delphi as well).
I got it
2014-09-19 18:23 GMT+08:00 Michael Schnell mschn...@lumino.de:
On 09/18/2014 10:32 AM, Xiangrong Fang wrote:
Unfortunately I do not get this working. When I instantiate TEvents
instead of TCriticalSections (and don't do much with same) the GUI
freezes. In fact I do this in the OnCreate
On 09/19/2014 02:48 PM, Xiangrong Fang wrote:
As far as I tried, you cannot use RTLEventWaitFor in main thread,
otherwise the gui will freeze.
Of course I did not do this. I used TEvent.Waitfor and I only used it in
the Execute function of the worker Threads .
Supposedly the problem was
Am 19.09.2014 14:49 schrieb Xiangrong Fang xrf...@gmail.com:
2014-09-19 18:23 GMT+08:00 Michael Schnell mschn...@lumino.de:
On 09/18/2014 10:32 AM, Xiangrong Fang wrote:
Unfortunately I do not get this working. When I instantiate TEvents
instead of TCriticalSections (and don't do much with
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
On 09/18/2014 12:13 AM, Graeme Geldenhuys wrote:
I haven't followed this whole thread, but I can add that the tiOPF
project (on SourceForge) has had a threadpool class for many years.
Well unit tested too.
Great ! Thanks. I'll take a look.
I did the TThreadPool class just for fun. I'll
2014-09-18 16:13 GMT+08:00 Michael Schnell mschn...@lumino.de:
I did the TThreadPool class just for fun. I'll compare the two thingies
and come back with some comments.
I don't quite understand the logic or difference between critical section
and events. My feeling is that to do
You said that you in fact did need or do an OnReady Event for each thread.
I just added that feature to TThreadPool: now each user Task (TTask
class) can be provided an OnReady Notify function.
Let me know if you want the extended code.
-Michael
--
On 09/18/2014 10:32 AM, Xiangrong Fang wrote:
I don't quite understand the logic or difference between critical section
and events.
They have nothing in common.
TCriticalSection is a Semaphore (see Wikipedia)
An event is a callback procedure -
On 09/18/2014 10:32 AM, Xiangrong Fang wrote:
how can you use a CS for the purpose of thread synchronization!
Thread synchronization is the only cause why TCriticalSection has been
invented (and provided with Delphi decades ago by Borland).
-Michael
--
On 09/18/2014 10:32 AM, Xiangrong Fang wrote:
2014-09-18 16:13 GMT+08:00 Michael Schnell mschn...@lumino.de
mailto:mschn...@lumino.de:
I did the TThreadPool class just for fun. I'll compare the two
thingies and come back with some comments.
I don't quite understand the logic or
On 09/18/2014 10:32 AM, Xiangrong Fang wrote:
Yesterday I read your ThreadPool source code, and cannot understand
how you control which thread can get the Wait CS, rather than just
let the 2 thread compete for it. Could you please explain the logic
behind this?
Each worker Thread (i.e.
Am 18.09.2014 11:03 schrieb Michael Schnell mschn...@lumino.de:
On 09/18/2014 10:32 AM, Xiangrong Fang wrote:
I don't quite understand the logic or difference between critical
section
and events.
They have nothing in common.
TCriticalSection is a Semaphore (see Wikipedia)
An
On 09/18/2014 11:36 AM, Sven Barth wrote:
A critical section is a mutex
OK. (but a mutex is constructed from a semphore, anyway, even if this
might be done in the OS). (I did this when doing my own special purpose
multitasking OS (in C), some 20 Years ago.)
and an event in this context is
On 09/18/2014 10:32 AM, Xiangrong Fang wrote:
I don't quite understand the logic or difference between critical section
and events.
Sorry for my previous rude reply.
Sven made me know that by event you did not mean an object pascal
language Event (i.e. a callback), but a TEvent instance.
On Thu, 18 Sep 2014 11:55:09 +0200
Michael Schnell mschn...@lumino.de wrote:
[...]
(It's a shame that the creators of our brand of the Object Pascal
Language once chose to invent new notions for commonly use concepts
(Callback - Event, Mutex - CriticalSection, TEvent - Semaphore, array
of
On 09/18/2014 12:10 PM, Mattias Gaertner wrote:
a Set is not an array of boolean
A set is an array (scientific English, not Pascal syntax) of bits
(i.e. boolean values) supported by special operators.
(Remember: Boolean Algebra and Logical Algebra are mathematically
equivalent).
The Set
On 09/18/2014 12:34 PM, Michael Schnell wrote:
Boolean Algebra and Logical Algebra are mathematically equivalent.
Sorry:
Set Algebra and Logical Algebra are mathematically equivalent.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On Thu, 18 Sep 2014 12:34:30 +0200
Michael Schnell mschn...@lumino.de wrote:
On 09/18/2014 12:10 PM, Mattias Gaertner wrote:
a Set is not an array of boolean
A set is an array (scientific English, not Pascal syntax) of bits
(i.e. boolean values) supported by special operators.
On planet
2014-09-18 17:55 GMT+08:00 Michael Schnell mschn...@lumino.de:
Sven made me know that by event you did not mean an object pascal
language Event (i.e. a callback), but a TEvent instance.
Sorry, I mean *neither*. I mean an RTLEvent. See this page:
On 09/18/2014 01:06 PM, Xiangrong Fang wrote:
What I need help to understand is, repeating my previous email: ...
I think, in the other mail, I did explain how Wait is supposed to work
in TThreadPool.
(And of course with some appropriate modifications of the source code,
you can use
2014-09-18 19:34 GMT+08:00 Michael Schnell mschn...@lumino.de:
I think, in the other mail, I did explain how Wait is supposed to work
in TThreadPool.
Initially, when the threadpool is created, Wait is hold by the main thread,
so the worker just wait there, no problem, but after the worker
On 09/18/2014 01:46 PM, Xiangrong Fang wrote:
2014-09-18 19:34 GMT+08:00 Michael Schnell mschn...@lumino.de
mailto:mschn...@lumino.de:
I think, in the other mail, I did explain how Wait is supposed
to work in TThreadPool.
Initially, when the threadpool is created, Wait is hold by
Michael Schnell wrote:
On 09/18/2014 12:10 PM, Mattias Gaertner wrote:
a Set is not an array of boolean
A set is an array (scientific English, not Pascal syntax) of bits
(i.e. boolean values) supported by special operators.
I suggest calling it a vector (supported by special operators) since
On 2014-09-16 12:44, Michael Schnell wrote:
I did a draft of a TThreadPool class.
Most of it works (creating assigning and re-assigning tasks works,
stopping the thing still produces an exception).
I haven't followed this whole thread, but I can add that the tiOPF
project (on SourceForge)
I did a draft of a TThreadPool class.
Most of it works (creating assigning and re-assigning tasks works,
stopping the thing still produces an exception).
If anybody wants to test it I can post the project.
-Michael
--
___
Lazarus mailing list
Hi Michael,
Could you please post it somewhere, e.g. github?
Thanks!
2014-09-16 19:44 GMT+08:00 Michael Schnell mschn...@lumino.de:
I did a draft of a TThreadPool class.
Most of it works (creating assigning and re-assigning tasks works,
stopping the thing still produces an exception).
If
I added a notify event for having both a single task and all task issue
an event when having don the scheduled work.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
2014-09-16 23:08 GMT+08:00 Michael Schnell mschn...@lumino.de:
I added a notify event for having both a single task and all task issue an
event when having don the scheduled work.
But where is the source please?
--
___
Lazarus mailing list
2014-09-15 17:12 GMT+08:00 Michael Schnell mschn...@lumino.de:
For better clearness, flexibility and portability I would use
Application.QueueAsyncCall instead (Or TThread.Queue, if you are on the svn
Version of fpc and would like to do it Delphi-compatible).
I would like to use the most
On 09/15/2014 11:17 AM, Xiangrong Fang wrote:
I DO need cross platform (linux/windows), but I do NOT want Delphi
compatibility, my app only compiles with FPC/Lazarus :-)
In that case I definitely would use Application.QueuAsyncCall.
-Michael
--
2014-09-15 17:23 GMT+08:00 Michael Schnell mschn...@lumino.de:
In that case I definitely would use Application.QueuAsyncCall.
If I understand correct, from this page:
http://wiki.freepascal.org/Asynchronous_Calls
QueueAsyncCall is, like what its name suggest, doing this in asynchronous
Am 15.09.2014 14:21 schrieb Xiangrong Fang xrf...@gmail.com:
2014-09-15 17:23 GMT+08:00 Michael Schnell mschn...@lumino.de:
In that case I definitely would use Application.QueuAsyncCall.
If I understand correct, from this page:
http://wiki.freepascal.org/Asynchronous_Calls
On 09/15/2014 02:19 PM, Xiangrong Fang wrote:
2014-09-15 17:23 GMT+08:00 Michael Schnell mschn...@lumino.de
mailto:mschn...@lumino.de:
In that case I definitely would use Application.QueuAsyncCall.
If I understand correct, from this page:
http://wiki.freepascal.org/Asynchronous_Calls
On 09/15/2014 02:19 PM, Xiangrong Fang wrote:
But what I need PostMessage for is to notify main thread (or another
thread)
You can only notify the main thread. There is no (standard) means to
notify another thread, as they don't have an event queue.
OTOH a worker thread is allowed to
On 09/15/2014 02:34 PM, Sven Barth wrote:
The synchronous alternative to PostMessage would be SendMessage,
though I don't know whether Lazarus provides this in a cross platform way
AFAIK, in Lazarus, SendMessage just directly calls the assigned event
handling function, and hence usually is only
2014-09-15 20:34 GMT+08:00 Sven Barth pascaldra...@googlemail.com:
If you want to use a separate thread (dispatcher) for enqueueing new
work you should create an event that you pass to this thread and the worker
threads. The dispatcher waits on the event and the worker threads will
signal the
On 09/15/2014 02:55 PM, Xiangrong Fang wrote:
How do I use Event to achieve the same?
What do you mean by Event ?
It seems that I can have N threads listen to the same event, but
cannot have the main thread to listen to N different events?
In fact Windows does provide event (aka Message)
2014-09-15 21:44 GMT+08:00 Michael Schnell mschn...@lumino.de:
Performance wise it's better not to destroy and create your threads but to
manage a thread pool and assign work to the threads as appropriate.
Here you would have the threads wait for work e.g. by trapping themselves
in a
On 09/15/2014 03:57 PM, Xiangrong Fang wrote:
2014-09-15 21:44 GMT+08:00 Michael Schnell mschn...@lumino.de
mailto:mschn...@lumino.de:
Performance wise it's better not to destroy and create your
threads but to manage a thread pool and assign work to the threads
as appropriate.
On Mon, 15 Sep 2014 21:57:40 +0800
Xiangrong Fang xrf...@gmail.com wrote:
[...]
That's exactly what I planed to do. But I don't know CriticalSections can
be used in here. My original thinking is that, by the end of Execute, I
call either PostMessage or QueueAsyncCall to notify main thread
2014-09-15 22:30 GMT+08:00 Michael Schnell mschn...@lumino.de:
Is that ok? To be exact, when a thread's execute() finished, it will go to
a sleep status,
No. It will die.
and can be reused by calling execute() again, right?
AFAIK: No.
What's the meaning of die? By calling execute() I
On 16.09.2014 00:06, Xiangrong Fang wrote:
2014-09-15 22:30 GMT+08:00 Michael Schnell mschn...@lumino.de
mailto:mschn...@lumino.de:
Is that ok? To be exact, when a thread's execute() finished, it
will go to a sleep status,
No. It will die.
and can be reused by calling
46 matches
Mail list logo
