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 s
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
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 <> s
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 prote
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_loc
[...]
coffee, pencil and stuff ;-)
off course, the local procedure "internalEnter" in Leave is a
copy'n'paste rubbish. Just remove ..
TCriticalSection.Leave;
begin
internal.lock;
try
if OwnerThread <> GetCurrentThreadID then begin //we are not
// allowed to leave, because we don't
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 miscon
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 p
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.
> >
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
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
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
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?
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
_
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.
> >
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 CurrentThrea
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
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 windo
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 u
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. c
Am Montag, 24. Juli 2006 20:33 schrieb Vinzent Höfler:
> 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 post
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
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:
> >
Florian Klaempfl wrote:
I didn't understand and follow the whole thread but please submit a bug
report if something in FPC needs to be fixed :)
Well, I'll do as soon as I'm sure if there's a bug. :)
Currently all I see is a subtle semantic difference between Windows- and
Unix-Event's impleme
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
http://lists.freepascal.org/mailman/listinfo/fpc-pas
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
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
called.
[..]
> ... 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 rtlwaiteve
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.
> >>
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 s
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) o
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 vot
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
> > >>>
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 creat
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 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
> 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 iteration:
Sounds like some recursion property is not set.
>
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.
38 matches
Mail list logo
