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
Hi,
For the life of me I cant remember what the functions are called to
enlarge or shrink a TRect by x pixels. Can anybody help me out? (I
know there was such functions in Delphi)
Regards,
Graeme.
--
There's no place like 127.0.0.1
___
fpc-pascal
Graeme Geldenhuys wrote:
Hi,
For the life of me I cant remember what the functions are called to
enlarge or shrink a TRect by x pixels. Can anybody help me out? (I
know there was such functions in Delphi)
InflateRect ?
Micha
___
fpc-pascal
That's the one!! Thanks.
Graeme.
On 7/25/06, Micha Nelissen [EMAIL PROTECTED] wrote:
Graeme Geldenhuys wrote:
Hi,
For the life of me I cant remember what the functions are called to
enlarge or shrink a TRect by x pixels. Can anybody help me out? (I
know there was such functions in
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
Andreas Berger schreef:
Andreas Berger wrote:
I have a problem compiling the compiler. After a lot of compilation it
attempts to compile pp.pas and I get the following error:
pp.pas(213,1) Error: Entrypoint start not defined.
I downloaded todays snapshot and had the same problem. Then I
What is this for? Although most threading implementations set this
record, it does not seem to be used by the system. The only
implementation that even calls the functions set is the unix
implementation, and it does it internally.
Do I need to use this if I implement threading in DOS?
On Tue, 25 Jul 2006, Andreas Berger wrote:
What is this for? Although most threading implementations set this record, it
does not seem to be used by the system.
It is most definitely used by the system :-)
All systhrdh.inc(systhrd.inc) functions use it.
The only implementation that even
On Tuesday 25 July 2006 14:18, Andreas Berger wrote:
In order to initialize threading under DOS I must create a separate
unit since I need the initialization and finalization clause. I
thought of using a cthreads.pp unit like in unix. However, the
TThread
implementation resides in the
On Tue, 25 Jul 2006, Andreas Berger wrote:
In order to initialize threading under DOS I must create a separate unit
since I need the initialization and finalization clause. I thought of using a
cthreads.pp unit like in unix. However, the TThread implementation resides in
the TThread.inc
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
This is a known error - I get it too - but I only get when using the v2.1.1
compiler to start make. Do you get it when starting with the v2.0.2 release
compiler released too? What about trying a snapshot of v20 compiler eg
base_go32_v20.zip or similar.
You can get more info with opt=-va on CL
At 22:18 24-7-2006, you wrote:
I'm new to free-pascal, and have searched for a few hours without
finding an answer to my question. I hope someone on the list could
please help point me in the right direction.
I've been using a couple of encryption/decryption units that are
written in Pascal
Vincent Snijders wrote:
Andreas Berger schreef:
Andreas Berger wrote:
I have a problem compiling the compiler. After a lot of compilation
it attempts to compile pp.pas and I get the following error:
pp.pas(213,1) Error: Entrypoint start not defined.
I downloaded todays snapshot and had the
23 matches
Mail list logo
