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
2009/9/19 Micha Nelissen :
>
> 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 way, internal impl
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
___
fpc-p
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
On 18 Sep 2009, at 12:12, Martin wrote:
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 tog
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 ms
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 cross-pla
Graeme Geldenhuys schrieb:
> 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 doe
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 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 - fpc-p
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,
- Graem
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}
WaitForSingleObject(Contin
> 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:
EnterCri
13 matches
Mail list logo