Vinzent Höfler wrote:
because we assume it's non-recursive, that was the whole point. So we
should *first* check the count and then may lock/unlock the mutex
accordingly.
Note that these two actions must be atomic. This is what the TryLock is for.
Micha
On Tuesday 25 July 2006 06:40, Micha Nelissen wrote:
Vinzent Höfler wrote:
because we assume it's non-recursive, that was the whole point. So
we should *first* check the count and then may lock/unlock the
mutex accordingly.
Note that these two actions must be atomic.
Oh, really?
This
Vinzent Hoefler wrote:
On Tuesday 25 July 2006 06:40, Micha Nelissen wrote:
Vinzent Höfler wrote:
because we assume it's non-recursive, that was the whole point. So
we should *first* check the count and then may lock/unlock the
mutex accordingly.
Note that these two actions must be atomic.
On Tuesday 25 July 2006 07:46, Micha Nelissen wrote:
Vinzent Hoefler wrote:
On Tuesday 25 July 2006 06:40, Micha Nelissen wrote:
Vinzent Höfler wrote:
because we assume it's non-recursive, that was the whole point.
So we should *first* check the count and then may lock/unlock the
mutex
Vinzent Hoefler wrote:
Ehm, no.
Ehm, yes. I was being ironic here. Of course, the action of checking the
counter and locking/unlocking the associated mutex must be atomic.
But here they are not associated, they're protected by owner_lock, as
you said.
Got confused a bit :-). Reread the
Am Dienstag, 25. Juli 2006 10:46 schrieb Micha Nelissen:
Vinzent Hoefler wrote:
Ehm, no.
Ehm, yes. I was being ironic here. Of course, the action of
checking the counter and locking/unlocking the associated mutex
must be atomic.
But here they are not associated, they're protected by
Burkhard Carstens wrote:
I don't see the need for Owner_Check_Lock anymore ? :-)
You have to prevent that 2 concurrent threads call lock simultanously,
No, why?
so you have to take an internal lock before touching internal vars like
self.ThreadID ?
No, why ? This is a common
On Tuesday 25 July 2006 09:04, Burkhard Carstens wrote:
Am Dienstag, 25. Juli 2006 10:46 schrieb Micha Nelissen:
function Recursive_Mutex.Lock:...;
begin
// Owned by current thread?
if CurrentThreadId self.ThreadId then
begin
result := pthread_mutex_lock (self...);
On Tuesday 25 July 2006 08:46, Micha Nelissen wrote:
Vinzent Hoefler wrote:
Ehm, no.
Ehm, yes. I was being ironic here. Of course, the action of
checking the counter and locking/unlocking the associated mutex
must be atomic.
But here they are not associated, they're protected by
Am Dienstag, 25. Juli 2006 11:59 schrieb Vinzent Hoefler:
On Tuesday 25 July 2006 09:04, Burkhard Carstens wrote:
Am Dienstag, 25. Juli 2006 10:46 schrieb Micha Nelissen:
function Recursive_Mutex.Lock:...;
begin
// Owned by current thread?
if CurrentThreadId self.ThreadId
Vinzent Hoefler wrote:
Ok, there's a glitch: The read and write of self.ThreadId is required to
be atomic, so that a thread entering may either see 0 or the owner's
thread id when checking, otherwise it could be possible, it sees its
own thread_id due to a partial update and *then* it goes
On Tuesday 25 July 2006 14:51, Micha Nelissen wrote:
Vinzent Hoefler wrote:
Ok, there's a glitch: The read and write of self.ThreadId is
required to be atomic, so that a thread entering may either see 0
or the owner's thread id when checking, otherwise it could be
possible, it sees its
Hi,
I am having troubles with porting Semaphores in a project under Linux.
Under Windows everything works fine, but under Linux my app keeps
freezing.
The project is tiOPF v2 (TechInsite Object Persistent Framework).
There is a class called TtiPool, that handles a pool of database
connections.
On Monday 24 July 2006 13:34, Marco van de Voort wrote:
When I run the Unit Tests and create a single Lock and the Unlock
it, all works fine. If I then iterrate that test by creating 10
locks and then call unlock 10 times, the Unit Tests freeze on the
following line with the second
On Mon, 24 Jul 2006, Vinzent Hoefler wrote:
On Monday 24 July 2006 13:34, Marco van de Voort wrote:
When I run the Unit Tests and create a single Lock and the Unlock
it, all works fine. If I then iterrate that test by creating 10
locks and then call unlock 10 times, the Unit Tests freeze on
On Monday 24 July 2006 14:09, Michael Van Canneyt wrote:
On Mon, 24 Jul 2006, Vinzent Hoefler wrote:
On Monday 24 July 2006 13:34, Marco van de Voort wrote:
When I run the Unit Tests and create a single Lock and the Unlock
it, all works fine. If I then iterrate that test by creating 10
Am Montag, 24. Juli 2006 16:19 schrieb Vinzent Hoefler:
On Monday 24 July 2006 14:09, Michael Van Canneyt wrote:
On Mon, 24 Jul 2006, Vinzent Hoefler wrote:
On Monday 24 July 2006 13:34, Marco van de Voort wrote:
When I run the Unit Tests and create a single Lock and the
Unlock it, all
On Monday 24 July 2006 14:57, Burkhard Carstens wrote:
I vote for more pascal based versions of TMutex, TSemaphore and
TEvent, that behaves just like the ones in Delphi and use the system
specific functions (like pthread stuff) only internally in their
simplest/most portable form.
I'd vote
Am Montag, 24. Juli 2006 17:27 schrieb Vinzent Hoefler:
On Monday 24 July 2006 14:57, Burkhard Carstens wrote:
I vote for more pascal based versions of TMutex, TSemaphore and
TEvent, that behaves just like the ones in Delphi and use the
system specific functions (like pthread stuff) only
Burkhard Carstens wrote:
Am Montag, 24. Juli 2006 17:27 schrieb Vinzent Hoefler:
- the rtlEvent works even with timeout (with my patch posted on
mantis), but this one clears the signaled state, when wait is
called.
*oh* Before the wait? That's not good. This cries for race conditions
and
Am Montag, 24. Juli 2006 19:22 schrieb Vinzent Höfler:
Burkhard Carstens wrote:
Am Montag, 24. Juli 2006 17:27 schrieb Vinzent Hoefler:
- the rtlEvent works even with timeout (with my patch posted on
mantis), but this one clears the signaled state, when wait is
called.
*oh* Before the
[..]
... As long as rtlevent is used with this
in mind, it should give a consistent behaviour on windows and linux.
this in mind means: The only way how rtlevent should be used is:
1. call rtlstartwait
2. start the code (e.g. start/resume a thread), that signals the event.
3. call rtlwaitevent
Burkhard Carstens wrote:
Am Montag, 24. Juli 2006 19:22 schrieb Vinzent Höfler:
Burkhard Carstens wrote:
Am Montag, 24. Juli 2006 17:27 schrieb Vinzent Hoefler:
- the rtlEvent works even with timeout (with my patch posted on
mantis), but this one clears the signaled state, when wait is
Burkhard Carstens wrote:
[..]
... As long as rtlevent is used with this
in mind, it should give a consistent behaviour on windows and linux.
this in mind means: The only way how rtlevent should be used is:
1. call rtlstartwait
2. start the code (e.g. start/resume a thread), that signals the
Vinzent Höfler wrote:
I didn't understand and follow the whole thread but please submit a bug
report if something in FPC needs to be fixed :)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Vinzent Höfler wrote:
Currently all I see is a subtle semantic difference between Windows- and
Unix-Event's implementation.
AFAICS, it's as close as it can get. You mean subtle as in, unimportant,
or as in, possibly fatal ? :-) If possibly fatal, describe when/how.
So for now all I can say is
Burkhard Carstens wrote:
Am Montag, 24. Juli 2006 20:33 schrieb Vinzent Höfler:
Burkhard Carstens wrote:
[..]
... As long as rtlevent is used with this
in mind, it should give a consistent behaviour on windows and
linux.
this in mind means: The only way how rtlevent should be used is:
1.
Micha Nelissen wrote:
Vinzent Höfler wrote:
Currently all I see is a subtle semantic difference between Windows- and
Unix-Event's implementation.
AFAICS, it's as close as it can get. You mean subtle as in, unimportant,
or as in, possibly fatal ? :-) If possibly fatal, describe when/how.
If
Am Montag, 24. Juli 2006 22:05 schrieb Vinzent Höfler:
Burkhard Carstens wrote:
Am Montag, 24. Juli 2006 20:33 schrieb Vinzent Höfler:
Burkhard Carstens wrote:
[..]
... As long as rtlevent is used with this
in mind, it should give a consistent behaviour on windows and
linux.
Burkhard Carstens wrote:
Am Montag, 24. Juli 2006 22:05 schrieb Vinzent Höfler:
Burkhard Carstens wrote:
Am Montag, 24. Juli 2006 20:33 schrieb Vinzent Höfler:
Burkhard Carstens wrote:
[..]
btw. this is not TEvent, we are talking about, it's rtlevent ..
TEvent (in synconjs) is implemented
Vinzent Höfler wrote:
Hmm. So we'd need a mutex inside a mutex. Now I know why they call it
recursive. ;) So it'll be something like that:
function Recursive_Mutex.Lock : ...;
begin
// Lock mutex inside mutex.
self.Owner_Check_Lock.Lock;
// Owned by current thread?
if
Am Montag, 24. Juli 2006 23:38 schrieb Vinzent Höfler:
Vinzent Höfler wrote:
Hmm. So we'd need a mutex inside a mutex. Now I know why they call
it recursive. ;) So it'll be something like that:
function Recursive_Mutex.Lock : ...;
begin
// Lock mutex inside mutex.
32 matches
Mail list logo
