Graeme Geldenhuys wrote:
So far I have single interface for create/destroy/lock/unlock of
semaphores for Windows, Linux, *BSD. The latter two is actually for all
A semaphore is not locked and unlocked, it is posted and waited for.
Micha
___
2009/9/19 Micha Nelissen mi...@neli.hopto.org:
A semaphore is not locked and unlocked, it is posted and waited for.
True, and to let it make even more sense (technically correct) one
might have to use method names like deccount() / inccount() or
grabitem() / releaseitem() etc etc...
Either
On Sat, 19 Sep 2009 10:25:20 +0200, Micha Nelissen wrote about Re:
[fpc-pascal] Re: getting started with threads:
Graeme Geldenhuys wrote:
So far I have single interface for create/destroy/lock/unlock of
semaphores for Windows, Linux, *BSD. The latter two is actually for
all
A semaphore
En/na Tobias Giesen ha escrit:
Also possible but not easier. Threads should not be started or
stopped for each task, instead they should wait for an event telling
them to continue with the next task. For example using SetEvent /
ResetEvent as well as:
{$ifdef win32}
Luca Olivetti het geskryf:
There are some cross-platform synchronization classes in syncobjs
http://www.freepascal.org/docs-html/fcl/syncobjs/index.html
And I'm working on cross-platform semaphore classes / methods because
the current ones in FPC are totally useless.
Regards,
- Graeme -
On 18 Sep 2009, at 10:12, Graeme Geldenhuys wrote:
And I'm working on cross-platform semaphore classes / methods because
the current ones in FPC are totally useless.
I guess you mean that there aren't any :)
Jonas
___
fpc-pascal maillist -
Jonas Maebe het geskryf:
I guess you mean that there aren't any :)
True and False. :) It was recommended to me that I use the methods
directly from the thread manager, then later it was not recommended.
Plus the methods available from the thread manager doesn't support
initial max values for
On 18 Sep 2009, at 11:42, Graeme Geldenhuys wrote:
Jonas Maebe het geskryf:
I guess you mean that there aren't any :)
True and False. :) It was recommended to me that I use the methods
directly from the thread manager, then later it was not recommended.
It's because there is no
just a question:
Should semaphores be on the thread manager?
because imho they are not realy thread related? They can be used by
threads, but they have lot's of other uses. Even communication between
processes of different applications. They are usually grouped together
with other IPC like
Florian Klaempfl het geskryf:
Hope you find a good cross platform solution :)
So far I have single interface for create/destroy/lock/unlock of
semaphores for Windows, Linux, *BSD. The latter two is actually for all
unix with posix systems. So no more IFDEF's and specific uses clauses
units in
But how can I prevent race conditions? If threads X and Y happen to
call the task assignment function at the same time, it seems to me
that they could both be assigned to the same task.
Use for example the cross-platform implementations of
Enter/LeaveCriticalSection. Like this:
11 matches
Mail list logo
