Hi folks,

It appears that this bug has been fixed. Where I can get a patch for this? This is a very high priority bug for us, and we are glad that it has already been addressed :-) . I am very eager to test the fix.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Boian Mitov wrote

It appears that this bug has been fixed. Where I can get a patch for this? This is a very high priority bug for us, and we are glad that it has already been addressed :-) . I am very eager to test the fix.

Please read the comments to http://bugs.freepascal.org/view.php?id=9472

There was/is no bug in the compiler and therefore nothing has been "fixed".

Jonas

Hi Jonas,

Thank you!
I don't understand. 0011503 is a major failure. Is it in the compiler or in some library?
This code:

  Atest := TTest.Create();
  Atest := NIL;

will release properly the reference at assignment to NIL

this code does not:

  Atest := TestFunc();
  Atest := NIL;

This is a huge problem. This code must work the same way in both cases but it does not. We are porting a huge library of over 4 million lines of code from Delphi. This is a major show stopper. I can probably take a look in the compiler as it will be much easier and faster for us to fix the compiler to be Delphi compatible rather than rewriting the libraries. They rely heavily on interfaces and the correct reference counting. Rewriting this even if desirable will delay the project with at least a definition when there are no active references to an interface it must be released. This is a total failure of the functionality.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Boian Mitov wrote

Thank you! I don't understand. 0011503 is a major failure. Is it in the compiler or in some library?

Please read the comments to http://bugs.freepascal.org/view.php? id=9472. The whole issue is discussed there in great detail.

There are active references, namely in an invisible temp. When this invisible temp is destroyed (at the function exit), the interface is freed.

It is wrong to assume that implicit temps which still contain references to interfaces (or ansistrings, or any other reference counted type) can never exist, because this is an implementation detail over which the compiler has full control. This can also happen in Delphi under certain circumstances by the way (namely if it cannot guarantee that optimising the interface assignment is safe without using a temp).

The purpose of automatic reference counting is simply that memory management is automated. It is not to guarantee the same semantics as what you would get in a manual reference counting scheme where you are in full control of when and where reference counts are increased and decreased. In principle, a periodic mark and sweep would also still be correct behaviour.

Newer versions of FPC optimise assignments of function results more aggressively so you will more often get reference counting behaviour like in Delphi, but we do not guarantee in any way that it will be 100% identical. We only emulate the Delphi language, not the implementation details of the Delphi compiler or code generator.

Jonas

Hi Jonas,

This functionality works in all versions of Delphi 5-2007. We support them all, and we have done so for years. We have no problems to compile with such optimizations turned off. We need proper reference counting. We have over 300 Delphi components in 5 released and 3 libraries under current development, spreading over 4 million lines of code. We are looking to port it to Linux, and other platforms. The Lazarus looks like the natural solution. We have no problems creating a clone of it, or developing alternative compiler from scratch. We plan to allow C++ users to also use the library, as we provide C++/MFC and .NET component wrappers to our customers. If we need to we can simply fix the compiler for our needs and sell only compiled C++ supporting versions, or if you agree to allow some override to the behavior we can support the Lazarus and free Pascal too. We believe that as one of the biggest component vendors in the world, our support for Lazarus will help the project a lot. However for that we crucially need this problem fixed. CodeGear has done fixes for us in the past, in order to help us continue to support the platform, as they have done for other vendors, and we are very, very grateful for that, and have help them (convert) many of our .NET customers. We will be equally grateful for any help you can offer in our attempts to support Lazarus. We believe this will only help the community, and the popularity of the product. I have downloaded the source, and I will see if we can tweak it and add some compiler option to support this somehow.
You can take a look at our currently available products here : www.mitov.com , and yes, we are working to make all this available in Lazarus ;-) .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

P.S. Another idea is to probably compile with our own clone of FreePascal, and just provide the compiled libraries as long as we keep them binary compatible ;-) . We can give the clone for free to our customers. This way you can still have the main version of FreePascal do whatever it wants, and we will have a version that behaves as we expect ;-) .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

It should IMHO not be too hard to make a switch -Osomething which forces immediate release of temps. That should ensure Delphi compatible behaviour - possibly at the cost of some performance.

If you can provide a patch to implement such a switch, I'm pretty confident it will be included.

But Jonas is correct in his statement that you are relying on some implementation detail which you should not rely on. That it works for you in Delphi is pure luck, and the right thing to do is to review your code.

Michael.

Hi Michael,

Thank you! I will be looking into the code, and see if I can add the functionality with some switch. We may redo the code, however it will probably take well over a year for fully rewriting it all, and it may not be necessarily a smart thing. Delphi unlike C++ does not have any form of function or block enclosement, and the interfaces are the closest thing to functional enclosement we have, aside from the error prone try/finally pair. If we lose it, we lose a major development tool :-( . It surely downgrades the Pascal language a notch. I hope however that sometime in the future we will finally have a real functional enclosement in Pascal, but who know ;-) .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

I have downloaded the source, and I will see if we can tweak it and add some compiler option to support this somehow.

If it would be that easy, we would have done it. It's simply a matter of the design of compiler/rtl how ref. counting is done. We must draw a border somewhere. The next step would be that people expect that procedures use only the registers delphi uses regardless of the calling conventions.

Feel free to submit a patch if you can create one which don't break other stuff, we will gladly accept it, but I fear this is not easy.

PS: It will help me a lot if you guys can at least pint me to what files I should be looking for to change the behavior of the "temp" ;-) .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Boian Mitov wrote

This functionality works in all versions of Delphi 5-2007. We support them all, and we have done so for years. We have no problems to compile with such optimizations turned off.

One final time: please read the comments to http://bugs.freepascal.org/view.php?id=9472 .

It's not an optimisation which needs to be turned off. On the contrary, you are depending on a particular optimisation to be performed (namely skipping the use of temporary function results when assigning the result of a function returning an interface to certain classes of local variables). The effects of this behaviour can also be emulated by clearing all temps immediately after their use, as Michael indicates, in which case you obviously get slower and much more bloated code (and make the compiler code itself also more complex).

I repeat: there is absolutely nothing wrong with using a temporary function result in such situations, and depending on it not being used is an error in your code. Your program will also break under Delphi e.g. when you assign the interface result of a nested functions to a local variable and also access this variable from the nested function.

You also have not explained why it is so crucial that the interfaces are immediately released.

We need proper reference counting.

There is proper reference counting: there are no memory leaks. That's really all that automatic reference counting guarantees.

You may also want to have a look at http://wiki.freepascal.org/Code_Conversion_Guide#Semantical_differences for a couple more implementation differences between Delphi and FPC.

Jonas

PS: It will help me a lot if you guys can at least pint me to what files I should be looking for to change the behavior of the "temp" ;-) .

See my other mail, this requires not only a simple change in a few files.

Gee... Isn't it the reason we all love C++ ;-) . There all those things are standardized by the ANSI, and return variable "temp" must be alive only for the duration of the statement if you want to call your compiler "ANSI" ;-) . Then again, don't we all hate the lack of support for singletons in C++ :-D . There is no such thing as a perfect language... We will figure out a way out of this ;-) .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

I can see that you really want this feature, this is for sure.

However, nowhere you write WHY you need this feature;

The behaviour you seem to expect is wrong by definition.

As stated:
There are *no* leaks. The memory is freed at procedure exit;
This is just a little later than what you expect. (you expect it right after the :=Nil;)

So WHY do you expect/need this behaviour ?

What architectural decision makes this necessary ?

I am asking this because I find it hard to believe that you would write conciously code which really depends on this feature.

Michael.

Thank you Florian, if needed, I will get couple of people to help me on this one. I appreciate your help!

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

To do this correct, you need however an implicit try ... finally statement around the clearing.

Here is a code sniped that sows just one example of the problem:

This is a very simple example of how important the order really is: We have even more crucial problems related with this. This is just a simple one:

destructor  TALBasicAudioOut.Destroy();
var
  WriteLock : IOWLockSection;
begin
  WriteLock := FLock.StopLock();
  FInputPin.Free();
  FEnablePin.Free();
  FMasterPumping.Free();
  WriteLock := NIL;
  FLock.Free();
  inherited;
end;

You can see that the WriteLock MUST be released before the FLock.Free();, otherwise you will have access violation, and this is a destructor, so the options are limited.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Do you have pg numbers in Strousstrup? (I've 2nd ed) I'd be interested to read how standards describes such things.

Maybe Jonas or Florian can comment on this.

Michael.

I will dig for it.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

When you said function blocks, it made me think of nested procedures.

So I think you write it like:

destructor  TALBasicAudioOut.Destroy();
  procedure DoWriteProtectedThings;
  var
    WriteLock : IOWLockSection;
  begin
  WriteLock := FLock.StopLock();
  FInputPin.Free();
  FEnablePin.Free();
  FMasterPumping.Free();
  end;
begin
  DoWriteProtectedThings;
  FLock.Free();
  inherited;
end;

Then you have made it clear that after WriteLock has to be cleared before freeing the lock. Of course it still fails if a periodic mark and sweep would be used by the compiler.

Vincent

I will see to ping somebody on the ANSI comity for this one. It takes forever to dig it out ;-) . I will let you know.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

I will see to ping somebody on the ANSI comity for this one. It takes forever to dig it out ;-) . I will let you know.

Thanks.

Here is a code sniped that sows just one example of the problem: This is a very simple example of how important the order really is:

Unfortunatly, I can quote only from the german delphi help: "Wenn Sie die Referenzzählung nutzen wollen, dürfen Sie das Objekt nur als Schnittstellenreferenz verwalten." It says, if you want to use the reference counting, you might store the class only as interface reference. I guess FLock is no interface?

Further, how is in delphi ensured that WriteLock:=Nil; doesn't release
FLock?

The .Free is probably the error here. If FLock inherits from TInterfacedObject, calling release is the way to go.

Reference counting only guarantees that
a) an instance will not be freed as long as any references to it exist b) an instance will be freed automatically after the last reference disappears

It does not guarantee/define
a) at which point in the code exactly an instance will be freed b) the actual mechanism used for reclaiming the memory (a simple free when the reference count hits zero, mark and sweep, ...)

It is therefore not a substitute for managing other kinds of resources which require predictable freeing points. The above example is conceptually identical to several of the examples given in the comments to http://bugs.freepascal.org/view.php?id=9472

It's similar to how you cannot use the Finalize method in Java to perform resource management, because it will only be called when the garbage collector reaps your instance and not necessarily immediately when the last reference to an instance is gone.

Jonas

Hi Florian,

FLock is not interface. There is no error with the FLock. WriteLock is interface, and I have to destroy it before I destroy the FLock. The order of destruction is obviously crucial.
The error is the fact that WriteLock referenced object is not released when WriteLock is assigned to NIL. I have found a number of work arounds for this, but some will not work in more complex scenarious :-( . As I mentioned this is a very simple case where the bug is obvious.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

This is not very precise. You are referring to garbage collection in general. Reference counting as it used to be defined in the original COM specification for DLL and statically linked objects specifically states that the object will be destroyed as soon as the last reference to it is lost. The non deterministic garbage collector is the exact reason we don't have stable Java programs, and they al tend to leak, and crash the systems. There is no Garbage collection per say for resources, and there is no function enclosement either. .NET has number of ugly language extensions "patches" to work around that in C#, but this is a whole different story. To be able to work with resources we have to have a tight control over their lifespan. otherwise we are in a grave danger of crashes. We can surely revert to the old days of doing that with functional programming, as Java developers tend to do, but that has all the disadvantages and dangers of functional programming. OOP is supposed to assist us in writing safe code, not endanger us.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Boian Mitov wrote

This is not very precise. You are referring to garbage collection in general. Reference counting as it used to be defined in the original COM specification for DLL and statically linked objects specifically states that the object will be destroyed as soon as the last reference to it is lost.

That is exactly what is implemented.

Just there is an invisible - to you - reference.

You mix explicit with implicit memory management (Flock.Free).

The Delphi help warns explicitly against this.
(see "Using reference counting")

Michael.

Hi Florian, FLock is not interface. There is no error with the FLock.

To which instance is WriteLock an interface? FLock?

Michael,

I never call Free() on interfaced object. I surely know that if I have used interfaces for the last 10 years or so ;-) .
What I need is a way to make sure that all the references are gone. This is the first non garbage collected compiler that has prevented me from releasing all the references so far. Delphi, the C++ COM libraries VB etc. they all have behaved in a predictable way. Lazarus is the first surprise for me ;-) . There is always a first time however.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Hi Marco,

I have found it :-)
This is one of the draft, but that part has hardly changed:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf

Page 244
Item 3 describes the lifespan of a temporary object in expression (rvalue life span):

3 When an implementation introduces a temporary object of a class that has a non-trivial constructor (12.1, 12.8), it shall

ensure that a constructor is called for the temporary object. Similarly, the destructor shall be called for a temporary

with a non-trivial destructor (12.4). Temporary objects are destroyed as the last step in evaluating the full-expression

(1.9) that (lexically) contains the point where they were created. This is true even if that evaluation ends in throwing

an exception. The value computations and side effects of destroying a temporary object are associated only with the

full-expression, not with any specific subexpression.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Michael, I never call Free() on interfaced object. I surely know that if I have used interfaces for the last 10 years or so ;-) .

See my other mail. You do a WriteLock:=FLock.StopLock(); call. Every interface is associated with a class instance. With which class instance is WriteLock associated?

Page 244 Item 3 describes the lifespan of a temporary object in expression (rvalue life span):

Ah, but this is a compiler generated object as result value. I'm still surprised btw that they omit this possible optimization (e.g. destruction with the frame), but that is probably related with the need to have the compiler always honor nested { } blocks.

Anyway, that is something else then a explicitely declared interface reference as we have here, so one needs a different example.

What comes close to an interface in behaviour in C++, smart pointers?

function  TOWLock.StopLock() : IOWLockSection;
begin
  Result := TOWSimpleStopLockSection.Create( Self );
end;

This is a completely different object.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

No,

function  TOWLock.StopLock() : IOWLockSection;
{$ENDIF}
begin
  Result := TOWSimpleStopLockSection.Create( Self );
end;
  With best regards,
    Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Hi Marco,

You are wrong. They mean expression not block!
This is one block with 3 expressions:

{
  a = 3 + 4;
  b = 5 + 3;
  c =  3 + 7;
}

If an temporary variable is created it must be destroyed before the ";" symbol, not at the end of the block!
This is vary good as it prevent any "optimization" to break your code ;-) . You know exactly where the destructor will be called on any ANSI C++ compiler in the world. This is the reason C++ remains my favorite language regardless of the many issues it has. It is 100% defined, and you know 100% what it will do ;-) .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Hi Marco, You are wrong. They mean expression not block!

This path of the discussion is useless. As soon as you make WriteLock a global/static var, delphi behaves the same as fpc: it creates a temp. ref. which is only cleaned at procedure exit.

Delphi doesn't, look at this example:

***
uses

   SysUtils;

type
   imyintf = interface
     function getrefcount: longint;
   end;
   tmyclass = class(tinterfacedobject,imyintf)
     function getrefcount: longint;
   end;
   function tmyclass.getrefcount: longint;
     begin
       result:=refcount;
     end;
procedure test;
var
   i: imyintf;
   function test2: imyintf;
     begin
       result:=tmyclass.create;
       writeln(i.getrefcount);
     end;
begin
   i:=tmyclass.create;
   i:=test2;
   writeln(i.getrefcount);
end;
begin
   test;
end.
***

The output is (when compiled with Kylix 3):
refcount of i in test2: 1
refcount of i after calling test2: 2

If you comment out the "writeln" in test2, then the result is: refcount of i after calling test2: 1

The reason is that if you access "i" inside test2, then Delphi cannot perform the optimisation of skipping the temp, and it also only frees the temp at the end of the function.

The behaviour you are counting on is a side effect of an optimisation, not a behaviour by design.

Jonas

Hi Florian,

Thank you!
This is false! In Delphi the interface is released immediately. Before you make such statement I advise you to verify the Delphi behavior. I can ensure you that D5, 6, 7, 2005, 2006, 2007 as well as BCB 5, 6, 2006, and 2007 will release the object before the end of the block. FPC behaves completely different way. As the best of my understanding they have implemented the TMP the same way as it is described in the ANSI C++ standard, but if you wish I can ask them. I will be meeting the CodeGear guys next week, and I can chat with them on that.

The information I provided was for the ANSI standard as the guy was interested how they have defined it ;-) .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Hi Florian, Thank you! This is false! In Delphi the interface is released immediately.

No.

Before you make such statement I advise you to verify the Delphi behavior.

I did so because I discussed this behaviour several times before. Just compare the output of and explain me your theory about it:

type
   tclass1 = class(TInterfacedObject)
     destructor destroy;override;
   end;
destructor tclass1.destroy;
   begin
     writeln('destroyed');
     inherited;
   end;
function f : IInterface;
   begin
     f:=tclass1.create;
   end;
var
   i : IInterface;
procedure p;
   begin
     i:=f;
     i:=nil;
     writeln('exiting');
   end;
begin
   p;
   writeln('back');
end.

and

type
   tclass1 = class(TInterfacedObject)
     destructor destroy;override;
   end;
destructor tclass1.destroy;
   begin
     writeln('destroyed');
     inherited;
   end;
function f : IInterface;
   begin
     f:=tclass1.create;
   end;
procedure p;
   var
     i : IInterface;
   begin
     i:=f;
     i:=nil;
     writeln('exiting');
   end;
begin
   p;
   writeln('back');
end.

I can ensure you that D5, 6, 7, 2005, 2006, 2007 as well as BCB 5, 6, 2006, and 2007 will release the object before the end of the block.

No.

The behaviour you are counting on is a side effect of an optimisation, not a behaviour by design.

Oh, btw: fpc 2.2.2rc1 behaves with -O2 like delphi :) Without -O2 like 2.2.0 :)

Thank you! I will see to get the 2.2.2rc1 and compile with the switch :-) . I will validate if it behaves the same way and will let you know :-) . I am very excited that there could be a ready solution :-) .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Add: I just realized that Peter implemented this some time ago in a "in most cases" (!) delphi compatible behaviour.

Hi Jonas,

Delphi seems to be a fairly good player in terms of this behavior. I have been using interfaces for many years, and they have worked as expected. You can verify this with the code snipped from the bug report. I am excited however by the last Florian post. I will have to figure out how to configure the Lazarus packages, and how to upgrade to rc 1 etc if needed, but it is very promising :-) .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Indeed: e.g., if you compile the example I posted with the "writeln" in test2 commented out, then Delphi will write out 1 as refcount later on and FPC still 2.

Jonas

Thank you! I will see to get the 2.2.2rc1 and compile with the switch :-) . I will validate if it behaves the same way and will let you know :-) . I am very excited that there could be a ready solution :-) .

I still recommend that you think about changing your design, see Jonas' and my mail why. In our opinion your code works by accident.

I understand and appreciate your input. If needed I will tweak some places of the library. This is not problem. We have done some other changes as well. As long as in most cases it works well we are happy ;-) . Porting all of our products will take months of work and effort, but we are committed. When we have it ported I will make sure you guys get a full source code commercial licenses ;-) .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

I mean get them for free ;-) .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Hmm... Florian, I seem to be finding only downloads for 2.2.0 . Where I can get 2.2.2rc1 ?

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Boian Mitov wrote

Hmm... Florian, I seem to be finding only downloads for 2.2.0 . Where I can get 2.2.2rc1 ?

See download link on www.freepascal.org main page, first (english) news item.

Michael.

The FTP server seems really slow to respond. Do you want me to setup an FTP account for you guys on one of my servers, so you can upload in the future Beta stuff there for easier access for everybody?

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Boian Mitov wrote

The FTP server seems really slow to respond. Do you want me to setup an FTP account for you guys on one of my servers, so you can upload in the future Beta stuff there for easier access for everybody?

There are many mirrors; The main site just points to the main one, you can simply pick any mirror and browse through the FTP site.

But a new mirror is always welcome.

Michael.

Hi Michael,

Finally the server responded. This file is not on the mirrors :-( . It is only on the FTP.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Hi Michael,

Maybe I was looking at the wrong place. I was looking at SourceForge initially, and saw 2.2.0 files only. I am still learning where the FreePascal files and resources are, so it could be my fault. Maybe they ware picking it and that is why it took me 50 minutes just to open the FTP directory ;-) .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Boian Mitov wrote

Hi Michael, Finally the server responded. This file is not on the mirrors :-( . It is only on the FTP.

Strange, I would think that the FTP mirrors picked it up by now ?

Michael.

Hi Folks,

After some fight trying to install the 2.2.2 in my Lazarus, I have found a daily Lazarus snapshot with it. After some testing I can confirm that can tell the "bug" is fixed. It works as I was expecting. Thank you for the fantastic job!
The Lazarus also seems to have improved considerably since the 0.9.24 release.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

My refactoring and optimization of the function return assignment handling is only available in 2.3.1. The change is too intrusive to backport it to 2.2.x.

Peter

Hi Peter,

Thank you!
So far it works just great. Can we hope for a separated switch for this specific "optimization" ;-) . I am running 2.2.2 now.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

I mean -O2 probably affects number of optimizations. I just hope there will be switches for turning off specific optimizations selectively.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

While on the discussion, are there any plans for Semaphore and Mutex in the libraries in the future? I will be writing my own implementations using the Events, but just curious if in the future they are planned to be offered. I have seen Semaphore used in the TThread implementation, but they are not available outside the unit, so I assume they are too platform specific. I think I can make implementation by using only events, critical sections and counters.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

I haven't followed the discussion so far, so what I might say may be out of context and not relevant.

Regarding semaphores and mutexes:
the implementation in Kylix of TEvent is incomplete in the sense that TEvent.WaitFor(timeout: Integer) does not work for any timeout other than $FFFFFFFF. Some time ago fpc was in the same situation and I don't known if that have been resolved. If it have been resolved, please disregard the rest of the post.

Anyways, some time ago I debuged the issue and patched kylix's SynObjs unit to cure that. Basically, the problem is, as expected, glibc. Older version did not have sem_timedwait() implemented. Later glibc included it, along with several new variants of the remaining semaphore routines. So, based on what thread model is used (LinuxThreads or NTPL) each semaphore routine is implemented several times. The thing is a total mess. Anyways, if one explicitly instructs the kylix linker which version of semaphore functions to use (they have to be consistent) TEvent.WaitFor can be implemnted for any timeout. If there is interest I can post the patch.

Peter Popov

Hi Peter,

Thank you!
I am already working to implement the Semaphores, and Mutexes. I need timeout. Can you please post the patch? This is actually very important issue, as the libraries use threads extensively, and share huge number of resources. The timeouts are needed to resolve deadlocks.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Where do you want me to post it?
Peter

Hi Peter,

I thought you ware part of the FreePascal team. If you don't have access to FTP, please let me know, and I will set account for you on one of my servers. I also believe the fix is important and should find its way to the Project at some point.
Thank you for your efforts!

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

I am not. As I explained, I was messing around with the Kylix implementation of SyncObjs

I don't know if this is currently a problem for FPC. At least version 2.0.4 had the issue (under linux).
If it still is, let me know.

I will see if I can post it on the unofficial CLX patches

Peter

It is good that it works for you now, but like Jonas already wrote. It is just pure luck and you rely on optimizations. Something that should not be done, because some optimizations make debugging hard.

In 2.2.2 there is a bit of function result reuse optimization, but it is limited. In 2.3.1 the handling is rewritten and made more generic. This rewrite affects too much code to be ever backported to 2.2.x

Peter

Boian Mitov wrote

I mean -O2 probably affects number of optimizations. I just hope there will be switches for turning off specific optimizations selectively.

Please use a separate thread for new questions.

See the -O switch help in 'fpc -h' how to turn on/off optimizations.

Peter

Hi Peter,

Thank you!
It works when the optimization is off. I was thanking for making it work, when the optimization is off. I do not rely on optimization. I am already looking to implement a mechanism to guard against the problems introduced by the optimization, and hope to have code that will behave properly even when it is on.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

I mean it was not working when the optimization was on. They did not have option to turn the optimization off.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Boian Mitov wrote

I mean it was not working when the optimization was on. They did not have option to turn the optimization off.

No, it can only work when the optimization is on in FPC. To recap:

a) in both FPC and Delphi, temps (regardless of their type) are never automatically finalized immediately after their last use, so they can retain references for a while
b) Delphi optimizes (possibly regardless of its optimization switch state) assignments of (reference counted) function results to local variables which cannot escape the current scope so that no temps are used (and hence no invisible references are created) c) FPC also optimizes these assignments as of 2.2.2, but under a few less circumstances than Delphi (see the example I posted with the nested functions)
d) in case of global variables or local variables which escape the current scope, both Delphi and FPC create temps which hold invisible references until these temps are reused for another purpose or go out of scope (per rule a).

Your programs are coded with the assumption that this optimization is always performed, which
a) is wrong for both Delphi and FPC in case global variables or local variables accessed outside their defining scope are used (as has been demonstrated using various programs posted to this mailing list) b) is wrong for FPC <= 2.2.0
c) is wrong for all current FPC versions in a few cases where the compiler can theoretically know that a local variable is not used outside its defining scope, but where it does not know that at this time

You keep however arguing that it is some mysterious optimization in FPC which causes the difference in behaviour (while it's actually a lack of a particular optimization that causes it), and that Delphi always does what you want (which it doesn't, as has been demonstrated using the example programs posted to this list).

Please understand that it is extremely tiring and frustrating to discuss in this way, because it gives the impression that you simply do not care about what causes the problem and/or simply are not listening to what we are trying to say.

So let me repeat one last time: Delphi optimizes assignments of reference counted function results to local variables which provably do not escape their defining scope so that they do not need a temp. FPC does this now also in most, but not all cases. Delphi, just like FPC, never automatically finalizes temps immediately after every statement in which they were used.

And while Delphi's optimization results in the behaviour you want for the code that you have written (and possibly the same behaviour which is explicitly defined in a number of other languages), it is pure luck that it does and it will have guaranteed different behaviour if you use global variables or local variables which can escape their defining scope. FPC does not guarantee to perform exactly the same optimizations as Delphi and therefore may also have different behaviour in a number of cases.

Jonas

Hi Jonas,

Thank you! I am already thinking of a permanent work around that will fix that regardless of the optimization or not. I think that by changing the Lock to be interface and doing few other tricks I may be able to achieve that, so the dependency on the way it works will not exist any more ;-) .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------