Re: [fpc-pascal] FPC on SPARC
Tomas Hajny wrote: > In any case, you might try compilation of sources exported from SVN tag > release_2_0_4_rc2 - starting with "make compiler_cycle" in fpcsrc > directory and then possibly continuing with release-like build. I guess > that this could be done using the makepack script, but I'm not doing any > Unix builds myself, so I'm not sure. You could check the > Release_engineering page in our Wiki > (http://www.freepascal.org/wiki/index.php/Release_engineering) for > additional information. It would be most welcome if you could provide us > with feedback regarding your results before this weekend. Thanks, noted. I'm very much a beginner at Open Source development, and I don't have SVN experience- that leaves me with a heck of a lot of work before I find my feet and I must stress that time is already a problem here. > BTW, can you compile for both sparc-linux and sparc-sunos, or just one of > them? Not sure yet. I've got Debian with 2.4 on one machine, and either 2.2 or Solaris v8 on another- in the latter case I think I have limited ability to update libraries since it took a lot of work getting the architecture running and I really don't want to break anything. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Semaphore problems
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. 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: if sem_wait(FSemaphore) <> 0 then raise EtiOPFInternalException.Create(cErrorTimedOutWaitingForSemaphore); * Under Linux, I am using the "pthreads" unit. What is the difference between the cthreads and pthreads unit? * The calls I am using from pthreads are: * sem_init() to create a semaphore * sem_wait() to lock the semaphore * sem_post() to unlock the semaphore All the above with a variable of type TSemaphore. Now, I have to admit, I don't know much about Semaphore's... Anybody know of some good documentation or tutorial on the net? Anything obvious I could be doing wrong? Regards, Graeme. -- There's no place like 127.0.0.1 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Semaphore problems
Looking at my code, I might have initialized my semaphore incorrectly.
The Windows portion works, and I tried to port it to Linux as follows...
procedure TtiPool.CreatePoolSemaphore;
begin
{$IFDEF MSWINDOWS}
if FSemaphore <> 0 then
CloseHandle( FSemaphore ) ;
FSemaphore := CreateSemaphore( nil, FiMaxPoolSize, FiMaxPoolSize, nil );
{$ENDIF MSWINDOWS}
{$IFDEF LINUX}
sem_destroy( FSemaphore );
if sem_init(FSemaphore, 0, 1) <> 0 then
raise Exception.Create('Failed to create the semaphore');
{$ENDIF LINUX}
end;
Regards,
Graeme.
On 7/24/06, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote:
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.
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:
if sem_wait(FSemaphore) <> 0 then
raise EtiOPFInternalException.Create(cErrorTimedOutWaitingForSemaphore);
* Under Linux, I am using the "pthreads" unit. What is the difference
between the cthreads and pthreads unit?
* The calls I am using from pthreads are:
* sem_init() to create a semaphore
* sem_wait() to lock the semaphore
* sem_post() to unlock the semaphore
All the above with a variable of type TSemaphore.
Now, I have to admit, I don't know much about Semaphore's... Anybody
know of some good documentation or tutorial on the net?
Anything obvious I could be doing wrong?
Regards,
Graeme.
--
There's no place like 127.0.0.1
--
There's no place like 127.0.0.1
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
> 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. > if sem_wait(FSemaphore) <> 0 then > raise EtiOPFInternalException.Create(cErrorTimedOutWaitingForSemaphore); > > * Under Linux, I am using the "pthreads" unit. What is the difference > between the cthreads and pthreads unit? pthreads is a straight header to the platforms POSIX pthreads library. It is as native to the pthreads lib on that platform as possible, so not 100% portable. Cthreads is a bit more complicated; Deep in the RTL/FCL and even the compiler we need threading primitives on *nix, but we don't want to import library pthread always, even if we don't use threading. So we defined a subset of pthreads with uniform typing, and programmed the RTL/FCL against an empty implementation of this interface that is always linked in. Cthreads is the _full_ implementation (that actually pulls in library pthreads) that is a unit on which no other units have any dependancy. By adding it to the project, the threading support is "armed". The Windows platform doesn't need this construct, since linking to the thread functions is not as potentially problematic, so thread support is installed always. So language threading, TCriticalSection and syncobjs are mostly built on top of this interface. Third, there is also the unit IPC, which is more an interface to kernel level IPC. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Semaphore problems
> Looking at my code, I might have initialized my semaphore incorrectly.
>
> The Windows portion works, and I tried to port it to Linux as follows...
>
> procedure TtiPool.CreatePoolSemaphore;
> begin
> {$IFDEF MSWINDOWS}
> if FSemaphore <> 0 then
> CloseHandle( FSemaphore ) ;
> FSemaphore := CreateSemaphore( nil, FiMaxPoolSize, FiMaxPoolSize, nil );
> {$ENDIF MSWINDOWS}
> {$IFDEF LINUX}
> sem_destroy( FSemaphore );
>
> if sem_init(FSemaphore, 0, 1) <> 0 then
> raise Exception.Create('Failed to create the semaphore');
> {$ENDIF LINUX}
> end;
Looking at unit syncobjs might save you some ifdefs and trouble.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Semaphore problems
On Monday 24 July 2006 10:21, Graeme Geldenhuys wrote:
> procedure TtiPool.CreatePoolSemaphore;
> begin
> {$IFDEF MSWINDOWS}
> if FSemaphore <> 0 then
> CloseHandle( FSemaphore ) ;
> FSemaphore := CreateSemaphore( nil, FiMaxPoolSize, FiMaxPoolSize,
> nil ); {$ENDIF MSWINDOWS}
> {$IFDEF LINUX}
> sem_destroy( FSemaphore );
>
> if sem_init(FSemaphore, 0, 1) <> 0 then
> raise Exception.Create('Failed to create the semaphore');
> {$ENDIF LINUX}
> end;
What is FiMaxPoolSize? I assume, it's something like a number of request
being allowed inside the semaphore-protected region at once?
So in the linux version only one thread is allowed being there.
I suppose you wrote something like
|for i := 0 to 9 do
|begin
| Lock;
| WriteLn ('Ping');
|end {for};
|
|for i := 0 to 9 do
|begin
| WriteLn ('Pong');
| Unlock;
|end {for};
In that case you're experiencing the lock-up when the semaphore is being
"entered"/locked the second time inside your loop. The counter is zero
after the first sem_wait and remains that way, because there's nobody
there to call the sem_post() operation. Well, it may seen as a kind of
a classical deadlock situation, although there's nothing classical in
here. ;)
That's what you're experiencing. Although it might appear similar, a
semaphore is *not* a mutex.
What I don't understand is why you don't use the "SyncObjs" unit where
almost all the stuff someone ever needs is nicely laid out in a
portable and object-oriented way.
> > if sem_wait(FSemaphore) <> 0 then
> > raise
> > EtiOPFInternalException.Create(cErrorTimedOutWaitingForSemaphore);
BTW, sem_wait() never returns anything else than zero, so checking is
sort of useless here. There's sem_trywait() for that, if you really
need to go so low-level.
To the question, what are semaphores. It's quite easily explained:
Atomic counters, you can only get past if they're non-zero and in that
case the counter is decremented.
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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 iteration: > > Sounds like some recursion property is not set. I don't think, semaphores have recursion properties. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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 the following line with the second iteration: Sounds like some recursion property is not set. I don't think, semaphores have recursion properties. They do, in some implementations. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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 > >>> 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. > > > > I don't think, semaphores have recursion properties. > > They do, in some implementations. Ok, granted. :) But not in POSIX, AFAICS. And they were never designed that way. I think, that's why someone invented the mutex. ;) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Semaphore problems
Hi Vinzent,
You got me one the right track, I think... :-)
I thought the counter in Semaphores get incremented, but as you stated
(and reading some Man Pages), they get decremented.
I then change my code from:
> if sem_init(FSemaphore, 0, 1) <> 0 then
> raise Exception.Create('Failed to create the semaphore');
to ...
> if sem_init(FSemaphore, 0, FiMaxPoolSize) <> 0 then
> raise Exception.Create('Failed to create the semaphore');
Which makes more sense now... FiMaxPoolSize is the maximum number of
requests being allow. Having it set to 1, I was only allowed 1, so
after the first Lock, the others ended in a deadlock type situation.
Hence the second iteration freezing the app.
What I don't understand is why you don't use the "SyncObjs" unit where
almost all the stuff someone ever needs is nicely laid out in a
portable and object-oriented way.
I didn't write the original Windows code, just tried to port it as is
to FPC and get the Unit Tests to pass. I will speak to the original
author and see what he thinks of you idea. As long as the code can
still compile under Delphi and FPC, I am sure everything should be
fine.
> > if sem_wait(FSemaphore) <> 0 then
> > raise
> > EtiOPFInternalException.Create(cErrorTimedOutWaitingForSemaphore);
BTW, sem_wait() never returns anything else than zero, so checking is
sort of useless here. There's sem_trywait() for that, if you really
need to go so low-level.
I changed it to sem_trywait() which pretty made all my tiPool unit
tests pass. For some strange reason I still get a lock-up, but much
less now. Say once every 5 iterations of the complete test suite
where-as before it was every time on a specific test case. I will now
try and implement the timeout work-around as suggested in the IBM
article below.
I found the IBM article very handy to explain some information.
http://tinyurl.com/n8jq9
Thanks for you time!
Regards,
Graeme.
--
There's no place like 127.0.0.1
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Semaphore problems
Looking at unit syncobjs might save you some ifdefs and trouble. Thanks for the tip. I always get hassled about keeping the IFDEF's as little as possible. I will go browse the SyncObjs unit now. Regards, Graeme. -- There's no place like 127.0.0.1 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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 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. > > > > > > I don't think, semaphores have recursion properties. > > > > They do, in some implementations. > > Ok, granted. :) But not in POSIX, AFAICS. > > And they were never designed that way. I think, that's why someone > invented the mutex. ;) hmm, so a mutex can be recursive, if the type is set correctly, which is not supportet on all platforms implementing pthread (man-pages of pthread). 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. Currently, I have the problem to get a working TEvent: - The one in syncobjs returns wrError, when it's waitfor is called with anything else tah infinite timeout - same goes for rtlbasicevent (cthreads) - the rtlEvent works even with timeout (with my patch posted on mantis), but this one clears the signaled state, when wait is called. IOW. if I call waitfor on the allready signalled event, it won't return before timeout. Also it doesn't inform the caller, wheter it returnt due to signalled or to timeout .. regards Burkhard ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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 for a more abstract version. :) The more or less basic things
needed in multi-threaded programing are
- semaphore
- persistent signal
- transient signal ("pulse")
- event
There's some more higher level stuff (like broadcasts, for example), but
that's about all you usually need. Currently we have the semaphore
(more or less as SyncObjs.tCriticalSection), the persistent and the
transient signal (SyncObjs.tEvent), although without timeouts (at least
when trying to be portable), the event is somewhat implemented, but
IIRC it misses a "Toggle" property, which can be used for simple
intertask communication ("Now I'm blocking, you're on.").
> Currently, I have the problem to get a working TEvent:
> - The one in syncobjs returns wrError, when it's waitfor is called
> with anything else tah infinite timeout
Yes, that's not implemented, although it should be easily added by using
condition variables of pthreads.
> - 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 subtle deadlock situations.
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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 internally in
> > their simplest/most portable form.
>
> I'd vote for a more abstract version. :) The more or less basic
> things needed in multi-threaded programing are
>
> - semaphore
> - persistent signal
> - transient signal ("pulse")
> - event
>
> There's some more higher level stuff (like broadcasts, for example),
> but that's about all you usually need. Currently we have the
> semaphore (more or less as SyncObjs.tCriticalSection), the persistent
> and the transient signal (SyncObjs.tEvent), although without timeouts
> (at least when trying to be portable), the event is somewhat
> implemented, but IIRC it misses a "Toggle" property, which can be
> used for simple intertask communication ("Now I'm blocking, you're
> on.").
>
> > Currently, I have the problem to get a working TEvent:
> > - The one in syncobjs returns wrError, when it's waitfor is called
> > with anything else tah infinite timeout
>
> Yes, that's not implemented, although it should be easily added by
> using condition variables of pthreads.
..which currently doesn't work, unless someone applies my patch (or a
better one) ..
>
> > - 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 subtle deadlock situations.
thread synchronization uses this and takes care of it by calling
RTLeventstartwait which locks the associated mutex. So I don't expect a
race condition there, but don't know about other places.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Compiling the compiler
I downloaded the latest snapshot and wish to recompile the fpc compiler for G032v2. I found an old doc that says to: cd compiler make cycle This obviously will not work since FPC has fpcmake and not make. There is also no makefile called cycle in the compiler folder. Can someone tell me how to completely recompile the fpc? regards, Andreas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling the compiler
Am Montag, 24. Juli 2006 17:42 schrieb Andreas Berger: > I downloaded the latest snapshot and wish to recompile the fpc > compiler for G032v2. I found an old doc that says to: > cd compiler > make cycle > > This obviously will not work since FPC has fpcmake and not make. > There is also no makefile called cycle in the compiler folder. Can > someone tell me how to completely recompile the fpc? AFAIK, fpcmake is another beast: it creates a Makefile based on infos in Makefile.fpc "make cycle" should call the "make" executable, which reads "Makefile" in the current folder and does stuff for the target "cycle" defined in "Makefile". however, never tried the go32v2 thing. only doing it on linux .. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling the compiler
Andreas Berger wrote: I downloaded the latest snapshot and wish to recompile the fpc compiler for G032v2. I found an old doc that says to: cd compiler make cycle This obviously will not work since FPC has fpcmake and not make. There is also no makefile called cycle in the compiler folder. Can someone tell me how to completely recompile the fpc? http://www.freepascal.org/moreinfo.html contains a link to the Building FAQ http://www.stack.nl/~marcov/buildfaq.pdf -- Sly This message and its attachments may contain legally privileged or confidential information. This message is intended for the use of the individual or entity to which it is addressed. If you are not the addressee indicated in this message, or the employee or agent responsible for delivering the message to the intended recipient, you may not copy or deliver this message or its attachments to anyone. Rather, you should permanently delete this message and its attachments and kindly notify the sender by reply e-mail. Any content of this message and its attachments, which does not relate to the official business of the sending company must be taken not to have been sent or endorsed by the sending company or any of its related entities. No warranty is made that the e-mail or attachment(s) are free from computer virus or other defect. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling the compiler
Steve Williams wrote: Andreas Berger wrote: I downloaded the latest snapshot and wish to recompile the fpc compiler for G032v2. I found an old doc that says to: cd compiler make cycle This obviously will not work since FPC has fpcmake and not make. There is also no makefile called cycle in the compiler folder. Can someone tell me how to completely recompile the fpc? http://www.freepascal.org/moreinfo.html contains a link to the Building FAQ http://www.stack.nl/~marcov/buildfaq.pdf Where would I download the GNU make.exe? It does not come with FPC. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling the compiler
> Steve Williams wrote: > > Andreas Berger wrote: > >> I downloaded the latest snapshot and wish to recompile the fpc > >> compiler for G032v2. I found an old doc that says to: > >> cd compiler > >> make cycle > >> > >> This obviously will not work since FPC has fpcmake and not make. > >> There is also no makefile called cycle in the compiler folder. Can > >> someone tell me how to completely recompile the fpc? > >> > > > > http://www.freepascal.org/moreinfo.html contains a link to the > > Building FAQ > > http://www.stack.nl/~marcov/buildfaq.pdf > > > Where would I download the GNU make.exe? It does not come with FPC. It does. However only with the releases, not with the snapshots. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE: [fpc-pascal] Compiling the compiler
Suggest you read these links - but from memory this is what you do. As was said before the utils are not included in snapshots- usually it's just the minimum there. A) you need to download the latest go32v2 release which is 2.0.2 eg from ftpmaster.freepascal.org or another ftp site, from /pub/fpc/dist/i386-go32v2-2.0.2/ You then install this, and this gives you the correct version of all of the gnu utils you need and the released compiler that's used to start the make. The utils include make & ld - some others are used in the make too B) Then you download the latest v2.1 source from /pub/fpc/snapshot/v21/source/fpc.zip & unzip it into a suitable directory, or get latest sources from svn if you can use it. Then, with the utils from step A in your path you do the 'make cycle' in ...\compiler & away you go. As was explained before, the makefiles are generated in fpc by another program and are included in the source... Of course you can use B for making the latest v2.0 (ie v2.0.3) as well, with suitable directory name change above to v20... BTW a new release 2.0.4, with a load of bug fixes, updates, is being prepared for release within next weeks - we are currently on rc2. Let us know if there are any problems & we may be able to use these to fix problems in the documentation for 2.0.4. Regards John > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Marco van > de Voort > Sent: 24 July 2006 17:05 > To: FPC-Pascal users discussions > Subject: Re: [fpc-pascal] Compiling the compiler > > > > Steve Williams wrote: > > > Andreas Berger wrote: > > >> I downloaded the latest snapshot and wish to recompile the fpc > > >> compiler for G032v2. I found an old doc that says to: > > >> cd compiler > > >> make cycle > > >> > > >> This obviously will not work since FPC has fpcmake and not make. > > >> There is also no makefile called cycle in the compiler > folder. Can > > >> someone tell me how to completely recompile the fpc? > > >> > > > > > > http://www.freepascal.org/moreinfo.html contains a link to the > > > Building FAQ > > > http://www.stack.nl/~marcov/buildfaq.pdf > > > > > Where would I download the GNU make.exe? It does not come with FPC. > > It does. However only with the releases, not with the snapshots. > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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 subtle deadlock situations. thread synchronization uses this and takes care of it by calling RTLeventstartwait which locks the associated mutex. As far as I just read code and comments, it does it for Windows to get Unix behaviour, although I don't see the point here, because this just forces the race condition the POSIX-Threads implementation actually tries to circumvent with this associated mutex. I'm not even sure, if Unix actually clears the event. The man-pages don't seem to indicate so. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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 wait? That's not good. This cries for race > >> conditions and subtle deadlock situations. > > > > thread synchronization uses this and takes care of it by calling > > RTLeventstartwait which locks the associated mutex. > > As far as I just read code and comments, it does it for Windows to > get Unix behaviour, although I don't see the point here, because this > just forces the race condition the POSIX-Threads implementation > actually tries to circumvent with this associated mutex. I don't think so. In unix, the mutex is locked, which ensures, there is not setevent between startwait and actual call to wait, because the call to wait seems to reset the cond, then releases the mutex and starts waiting. In windows, this doesn't matter (resetting the event on startwait), because it preserves the signaled state of the event. The wait call just returns immediately, if the event is allready signaled. To me, this is fine. As long as rtlevent is used with this in mind, it should give a consistent behaviour on windows and linux. (see classes.inc thread synchronization) > I'm not even sure, if Unix actually clears the event. The man-pages > don't seem to indicate so. It does, at least with the timedwait. I tested that extensively. Burkhard ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
[..] > ... 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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.
*oh* Before the wait? That's not good. This cries for race
conditions and subtle deadlock situations.
thread synchronization uses this and takes care of it by calling
RTLeventstartwait which locks the associated mutex.
As far as I just read code and comments, it does it for Windows to
get Unix behaviour, although I don't see the point here, because this
just forces the race condition the POSIX-Threads implementation
actually tries to circumvent with this associated mutex.
>
I don't think so.
Well, in that case either I am totally stupid (won't be news, anyway) or
I must have different source code:
From "rtl/unix/cthreads.inc":
|procedure intRTLEventStartWait(AEvent: PRTLEvent);
|var p:pintrtlevent;
|
|begin
| p:=pintrtlevent(aevent);
| pthread_mutex_lock(@p^.mutex);
|end;
|
|procedure intRTLEventWaitFor(AEvent: PRTLEvent);
|var p:pintrtlevent;
|
|begin
| p:=pintrtlevent(aevent);
| pthread_cond_wait(@p^.condvar, @p^.mutex);
| pthread_mutex_unlock(@p^.mutex);
|end;
Which is pretty much what you described and if pthread_cond_wait() works
as described, there's no race condition here.
But now "rtl/win/systhrd.inc":
|procedure intRTLEventStartWait(AEvent: PRTLEvent);
|begin
| { this is to get at least some common behaviour on unix and win32:
|events before startwait are lost on unix, so reset the event on
|win32 as well }
| ResetEvent(THANDLE(AEvent));
|end;
|
|procedure intRTLEventWaitFor(AEvent: PRTLEvent);
|const
| INFINITE=dword(-1);
|begin
| WaitForSingleObject(THANDLE(AEvent), INFINITE);
|end;
I don't see any locking in intRTLEventStartWait(), but I see the signal
being cleared in an unprotected way. So the signal can still get set
between the calls to intRTLStartWait() and intRTLEventWaitFor() which
makes the clearing quite useless.
In unix, the mutex is locked, which ensures, there is
not setevent between startwait and actual call to wait, because the
call to wait seems to reset the cond, then releases the mutex and
starts waiting.
Yes, and now I seem to understand why. Unix only implements transient
signals. So if there's noone waiting on the signal, it gets lost.
Windows OTOH seems to implement persistent signals. That's all the
difference.
> In windows, this doesn't matter (resetting the event on
startwait), because it preserves the signaled state of the event.
It preserves the signalled state? By resetting it? I don't think so.
AFAICS, it resets the signal before actually starting to wait for it. So
it still can sneak in if the timing is right. That's what I'd call a
race condition.
> The wait call just returns immediately, if the event is allready
signaled.
To me, this is fine. As long as rtlevent is used with this in mind, it
should give a consistent behaviour on windows and linux. (see
classes.inc thread synchronization)
You mean code like:
|if timeout>0 then
| begin
|RtlEventStartWait(SynchronizeTimeoutEvent);
|RtlEventWaitFor(SynchronizeTimeoutEvent,timeout);
| end
| else
|RtlEventResetEvent(SynchronizeTimeoutEvent);
So where's the code that makes sure that the thread signalling the event
is (only) resumed between the two calls?
I'm not even sure, if Unix actually clears the event. The man-pages
don't seem to indicate so.
It does, at least with the timedwait. I tested that extensively.
Yes, and now I think we both know why. I seem to repeat myself, but it
might be important: The difference is all between implementing transient
and persistent signals.
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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 event. 3. call rtlwaitevent Great. ;( But there's a flaw in this: If I'd actually know that thread A had been executed rtlstartwait() before thread B tries signalling the condition, I wouldn't need the whole synchronization at all. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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-pascal
Re: [fpc-pascal] Semaphore problems
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 implementation. So for now all I can say is that this should either a) be documented, b) changed to a common semantic behaviour, or c) ignored, because I'm just too stupid. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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. call rtlstartwait > > 2. start the code (e.g. start/resume a thread), that signals the > > event. 3. call rtlwaitevent > > Great. ;( But there's a flaw in this: If I'd actually know that > thread A had been executed rtlstartwait() before thread B tries > signalling the condition, I wouldn't need the whole synchronization > at all. You want to be sure, a thread started in step 2 has finished, before you proceed to step 4 .. btw. this is not TEvent, we are talking about, it's rtlevent .. TEvent (in synconjs) is implemented differently, and should work like delphi/ windows TEvent, except that it is not capable of timedwait .. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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 that this should either > > a) be documented, *Could* be a good idea, yes ;-). > b) changed to a common semantic behaviour, or They're both more or less 'transient' now. I am not sure how to emulate windows behavior on unix, although that behavior is easier to use I think, so would be desirable. Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling the compiler
Lee, John wrote: Suggest you read these links - but from memory this is what you do. As was said before the utils are not included in snapshots- usually it's just the minimum there. A) you need to download the latest go32v2 release which is 2.0.2 eg from ftpmaster.freepascal.org or another ftp site, from /pub/fpc/dist/i386-go32v2-2.0.2/ You then install this, and this gives you the correct version of all of the gnu utils you need and the released compiler that's used to start the make. The utils include make & ld - some others are used in the make too B) Then you download the latest v2.1 source from /pub/fpc/snapshot/v21/source/fpc.zip & unzip it into a suitable directory, or get latest sources from svn if you can use it. Then, with the utils from step A in your path you do the 'make cycle' in ...\compiler & away you go. As was explained before, the makefiles are generated in fpc by another program and are included in the source... Of course you can use B for making the latest v2.0 (ie v2.0.3) as well, with suitable directory name change above to v20... BTW a new release 2.0.4, with a load of bug fixes, updates, is being prepared for release within next weeks - we are currently on rc2. Thanks for the clear instructions. This should really be in the FAQ or Wiki. Just a few questions: - Will the 2.0.x tree be integrated into the 2.1.x tree? - Why are there two branches? - To integrate threading into DOS should I use 2.0.x or 2.1.x? Regards, Andreas Let us know if there are any problems & we may be able to use these to fix problems in the documentation for 2.0.4. Regards John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Marco van de Voort Sent: 24 July 2006 17:05 To: FPC-Pascal users discussions Subject: Re: [fpc-pascal] Compiling the compiler Steve Williams wrote: Andreas Berger wrote: I downloaded the latest snapshot and wish to recompile the fpc compiler for G032v2. I found an old doc that says to: cd compiler make cycle This obviously will not work since FPC has fpcmake and not make. There is also no makefile called cycle in the compiler folder. Can someone tell me how to completely recompile the fpc? http://www.freepascal.org/moreinfo.html contains a link to the Building FAQ http://www.stack.nl/~marcov/buildfaq.pdf Where would I download the GNU make.exe? It does not come with FPC. It does. However only with the releases, not with the snapshots. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling the compiler
On Mon, 24 Jul 2006, Andreas Berger wrote: > > > > BTW a new release 2.0.4, with a load of bug fixes, updates, is being > > prepared for release within next weeks - we are currently on rc2. > > > Thanks for the clear instructions. This should really be in the FAQ or Wiki. > > Just a few questions: > - Will the 2.0.x tree be integrated into the 2.1.x tree? No. It's rather the reverse: fixes done in 2.1 are merged back to 2.0 > - Why are there two branches? To keep new development (i.e. things that fall outside of fixes) out of 2.0. > - To integrate threading into DOS should I use 2.0.x or 2.1.x? 2.1.x because 2.0.4 is the last 2.0 release. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling the compiler
Michael Van Canneyt wrote: > > 2.1.x because 2.0.4 is the last 2.0 release. All new development is done in trunk or a branch of trunk. If things prove that they are working, they are merged to fixes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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 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 subtle deadlock situations.
> >>>
> >>> thread synchronization uses this and takes care of it by calling
> >>> RTLeventstartwait which locks the associated mutex.
> >>
> >> As far as I just read code and comments, it does it for Windows to
> >> get Unix behaviour, although I don't see the point here, because
> >> this just forces the race condition the POSIX-Threads
> >> implementation actually tries to circumvent with this associated
> >> mutex.
> >
> > I don't think so.
>
> Well, in that case either I am totally stupid (won't be news, anyway)
> or I must have different source code:
I am sure, you're not ;-)
> From "rtl/unix/cthreads.inc":
> |procedure intRTLEventStartWait(AEvent: PRTLEvent);
> |var p:pintrtlevent;
> |
> |begin
> | p:=pintrtlevent(aevent);
> | pthread_mutex_lock(@p^.mutex);
> |end;
> |
> |procedure intRTLEventWaitFor(AEvent: PRTLEvent);
> |var p:pintrtlevent;
> |
> |begin
> | p:=pintrtlevent(aevent);
> | pthread_cond_wait(@p^.condvar, @p^.mutex);
here, the mutex is unlocked, and wait state is entered, If timeout
occours or cond gets signalled, mutex is locked again and wait returns
> | pthread_mutex_unlock(@p^.mutex);
> |end;
>
> Which is pretty much what you described and if pthread_cond_wait()
> works as described, there's no race condition here.
>
> But now "rtl/win/systhrd.inc":
> |procedure intRTLEventStartWait(AEvent: PRTLEvent);
> |begin
> | { this is to get at least some common behaviour on unix and win32:
> |events before startwait are lost on unix, so reset the event on
> |win32 as well }
> | ResetEvent(THANDLE(AEvent));
> |end;
> |
> |procedure intRTLEventWaitFor(AEvent: PRTLEvent);
> |const
> | INFINITE=dword(-1);
> |begin
> | WaitForSingleObject(THANDLE(AEvent), INFINITE);
> |end;
>
> I don't see any locking in intRTLEventStartWait(), but I see the
> signal being cleared in an unprotected way. So the signal can still
> get set between the calls to intRTLStartWait() and
> intRTLEventWaitFor() which makes the clearing quite useless.
Yea, but as it's windows, that doesn't matter. setting the signal
between startwait and waitfor doesn't hurt, because windows doesn't
reset it before waiting. Resetting it in startwait just ensures, that
we have roughly the same behaviour like in unix, i.e. clear any
previously set signal and catch anything that gets signalled between
the call to startwait and return of waitfor...
> > In unix, the mutex is locked, which ensures, there is
> > not setevent between startwait and actual call to wait, because the
> > call to wait seems to reset the cond, then releases the mutex and
> > starts waiting.
>
> Yes, and now I seem to understand why. Unix only implements transient
> signals. So if there's noone waiting on the signal, it gets lost.
> Windows OTOH seems to implement persistent signals. That's all the
> difference.
right.
> > In windows, this doesn't matter (resetting the event on
> >
> > startwait), because it preserves the signaled state of the event.
>
> It preserves the signalled state? By resetting it? I don't think so.
I mean: it doesn't reset it on the waitforsingleobject call, at least
not *before* it starts waiting ..
> AFAICS, it resets the signal before actually starting to wait for it.
> So it still can sneak in if the timing is right. That's what I'd call
> a race condition.
>
> > The wait call just returns immediately, if the event is allready
>
> signaled.
>
> > To me, this is fine. As long as rtlevent is used with this in mind,
> > it should give a consistent behaviour on windows and linux. (see
> > classes.inc thread synchronization)
>
> You mean code like:
> |if timeout>0 then
> | begin
> |RtlEventStartWait(SynchronizeTimeoutEvent);
> |RtlEventWaitFor(SynchronizeTimeoutEvent,timeout);
> | end
> | else
> |RtlEventResetEvent(SynchronizeTimeoutEvent);
>
> So where's the code that makes sure that the thread signalling the
> event is (only) resumed between the two calls?
You are right! Looks like this is a bug! However, in unix, this would't
hurt anyway, as RtlEventWaitFor with timeout allways returns
immediately (mantis #7196) ;-)
Guess, no one tried to use checksynchonize with timeout <> 0 yet,
otherwise, we'd have a bugreport :-)
> >> I'm not even sure, if Unix actually clears the event. The
> >> man-pages don't seem to indicate so.
> >
> > It does, at least with the timedwait. I tested that extensively.
>
> Yes, and now I think we both know why. I seem to repeat myself, but
> it might be important:
Re: [fpc-pascal] Semaphore problems
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. call rtlstartwait 2. start the code (e.g. start/resume a thread), that signals the event. >>> 3. call rtlwaitevent >> Great. ;( But there's a flaw in this: If I'd actually know that thread A had been executed rtlstartwait() before thread B tries signalling the condition, I wouldn't need the whole synchronization at all. You want to be sure, a thread started in step 2 has finished, before you proceed to step 4 .. Ahh, yes. Now I see where you're going. What you're saying is that RTLEvent can't be used asynchronously (i.e. from different threads signalling each other) in a consistent way. Well, *that* should be documented. I thought, trying to achieve exactly that behaviour was the whole idea. btw. this is not TEvent, we are talking about, it's rtlevent .. TEvent (in synconjs) is implemented differently, and should work like delphi/ windows TEvent, except that it is not capable of timedwait .. Well, if I'm looking at it correctly that's only because its implementation is based on the POSIX semaphore. It could be using the phtread_mutex stuff instead. The pthread-primitives are used anyway, so I don't see problems with dependencies on libpthread/libc or so... Hmm, *looking closer* ... are there any differences between Darwin/BSD/Linux/Solaris code at all? AFAICS, all these implementations could be merged into a single one for Unix/POSIX targets. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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 used incorrectly, i.e. asynchronously. So for now all I can say is that this should either a) be documented, *Could* be a good idea, yes ;-). b) changed to a common semantic behaviour, or They're both more or less 'transient' now. Depends on the view point. Doing two consecutive waits() might do very different things. :) So I'd say, the behaviour and intended use should definitely be documented. I am not sure how to emulate windows behavior on unix, although that behavior is easier to use I think, so would be desirable. You'd have to create an own abstraction about the useful primitives. That's what I was initially talking about. :) Dunno, if that's good for the RTL, because you'd probably loose /some/ speed on the way... Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] linking an fpc .o file without common symbols?
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 that I've been using in a userspace networking tool for some time. For performance reasons, I want to move those routines out of userspace and implement an iptables match (Linux kernel module) and invoke the pascal routine. After much trial and error, I have successfully compiled a Linux kernel module, my fpc-generated .o file, system.o and objpas.o together. However, when I load the module, the kernel refuses it because it contains common symbols, and suggests that I recompile with the "-fno-common" flag (gcc flag?). After some research, nm system.o shows 30 or so symbols marked as ' C ', for common. Is there any way for me to tell the fpc compiler to re-compile system.o and initialize the 30 or so symbols so that they won't be marked as "common"? -Dan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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. > >>> > >>> "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 > >> > >> Great. ;( But there's a flaw in this: If I'd actually know that > >> thread A had been executed rtlstartwait() before thread B tries > >> signalling the condition, I wouldn't need the whole > >> synchronization at all. > > > > You want to be sure, a thread started in step 2 has finished, > > before you proceed to step 4 .. > > Ahh, yes. Now I see where you're going. What you're saying is that > RTLEvent can't be used asynchronously (i.e. from different threads > signalling each other) in a consistent way. > > Well, *that* should be documented. I thought, trying to achieve > exactly that behaviour was the whole idea. > > > btw. this is not TEvent, we are talking about, it's rtlevent .. > > TEvent (in synconjs) is implemented differently, and should work > > like delphi/ windows TEvent, except that it is not capable of > > timedwait .. > > Well, if I'm looking at it correctly that's only because its > implementation is based on the POSIX semaphore. It could be using the > phtread_mutex stuff instead. The pthread-primitives are used anyway, > so I don't see problems with dependencies on libpthread/libc or > so... My idea was to use a rtlevent additionally and only when waitfor is called with timeout AND event is not signalled yet. > Hmm, *looking closer* ... are there any differences between > Darwin/BSD/Linux/Solaris code at all? AFAICS, all these > implementations could be merged into a single one for Unix/POSIX > targets. Don't know, maybe. However, we use PTHREAD_MUTEX_RECURSIVE_NP, where NP stands for NotPortable.. don't know which platforms support it and which not. That's why I voted for implementing most of the functionality in pascal and use pthread primitives only in their basic (i.e. mutex in non-recursive) form.. Burkhard ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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 differently, and should work
like delphi/ windows TEvent, except that it is not capable of
timedwait ..
Well, if I'm looking at it correctly that's only because its
implementation is based on the POSIX semaphore. It could be using the
phtread_mutex stuff instead. The pthread-primitives are used anyway,
so I don't see problems with dependencies on libpthread/libc or
so...
My idea was to use a rtlevent additionally and only when waitfor is
called with timeout AND event is not signalled yet.
Why additionally? Do I miss something here? If done the proper way,
everything in SyncObjs should be based on the basic RTL stuff. This
would make the SyncObjs unit system independent with clearly defined
semantics on all targets.
Of course, the original implementation (I suppose it came from Delphi?)
was very windows-centric and made use of the available
Windows-primitives directly. So maybe for Win32 it should even be kept
this way, if not for anything else, somebody may say, for performance
reasons at least.
Hmm, *looking closer* ... are there any differences between
Darwin/BSD/Linux/Solaris code at all? AFAICS, all these
implementations could be merged into a single one for Unix/POSIX
targets.
Don't know, maybe. However, we use PTHREAD_MUTEX_RECURSIVE_NP, where NP
stands for NotPortable.. don't know which platforms support it and
which not.
Well, those flags are somhow there, but there marked "XSI" in the
OpenGroup's current specification, so probably most of our targets
implement it - but it's still an extension.
That's why I voted for implementing most of the functionality in pascal
and use pthread primitives only in their basic (i.e. mutex in
non-recursive) form.
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 CurrentThreadId <> self.ThreadId then
begin
// Nope! Get the hell outta here.
self.Owner_Check_Lock.Unlock;
exit (NOT_OWNED);
end {if};
// Now try locking the real mutex.
if pthread_mutex_lock (self...) = 0 then
begin
self.Count := self.Count + 1;
self.Owner_Check.Unlock;
exit (SUCCESS);
end {if};
self.Owner_Check.Unlock;
exit (FAILURE);
end {Mutex.Lock};
Something like that. Don't nail me on that, it's quite late and the heat
is still killing me. ;)
Well, a simple spinlock would even be better here for performance
reasons, because first the locking time should be quite small, and
second usually this code will be called in a sequential manner from
within the same thread anyway. This would make the lock always being in
an unlocked state under all sane circumstances.
Maybe even some overflow check in case someone tries to lock the mutex
more than 2**32 times in a row? ;)
Same for unlock etc.
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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 CurrentThreadId <> self.ThreadId then
begin
// Nope! Get the hell outta here.
self.Owner_Check_Lock.Unlock;
exit (NOT_OWNED);
end {if};
// Now try locking the real mutex.
if pthread_mutex_lock (self...) = 0 then
begin
self.Count := self.Count + 1;
self.Owner_Check.Unlock;
exit (SUCCESS);
end {if};
self.Owner_Check.Unlock;
exit (FAILURE);
end {Mutex.Lock};
Something like that. Don't nail me on that, it's quite late and the heat
is still killing me. ;)
I knew it. Of course this is wrong. We can only lock the mutex once,
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.
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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.
> >self.Owner_Check_Lock.Lock;
> >
> >// Owned by current thread?
> >if CurrentThreadId <> self.ThreadId then
> >begin
> > // Nope! Get the hell outta here.
> > self.Owner_Check_Lock.Unlock;
> > exit (NOT_OWNED);
> >end {if};
> >
> >// Now try locking the real mutex.
> >if pthread_mutex_lock (self...) = 0 then
> >begin
> > self.Count := self.Count + 1;
> > self.Owner_Check.Unlock;
> > exit (SUCCESS);
> >end {if};
> >
> >self.Owner_Check.Unlock;
> >exit (FAILURE);
> > end {Mutex.Lock};
> >
> > Something like that. Don't nail me on that, it's quite late and the
> > heat is still killing me. ;)
>
> I knew it. Of course this is wrong. We can only lock the mutex once,
> 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.
yea, this stuff is allways really brain cracking ;-) .. heat kills me,
too, so I will re-read these mails tomorrow and think about it again..
good night
Burkhard
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling the compiler
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. Regards, Andreas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
