[fpc-devel] Issue with Critical sections

[Sergei Gorelkin]

Hello,

I was porting to Linux some Windows code which uses critical
sections API, and got 'Identifier not found' error on InitializeCriticalSection and
DeleteCriticalSection symbols. After searching through RTL code, I
discovered that abovementioned functions are named InitCriticalSection
and DoneCriticalSection. At the same time, the EnterCriticalSection
and LeaveCriticalSection are not renamed, so code using them compiles
without errors. Why this inconsistency? Should I supply a patch that
adds Initialize/DeleteCriticalSection as aliases for
Init/DoneCriticalSection?

Regards,
Sergei

[Vinzent Hoefler]

Post by Sergei Gorelkin
I was porting to Linux some Windows code which uses critical
sections API, and got 'Identifier not found' error on
InitializeCriticalSection and DeleteCriticalSection symbols.

If I had to guess, I'd say this is probably because those identifiers
come from the Windows unit.

Post by Sergei Gorelkin
After
searching through RTL code, I discovered that abovementioned
functions are named InitCriticalSection and DoneCriticalSection. At
the same time, the EnterCriticalSection and LeaveCriticalSection are
not renamed, so code using them compiles without errors. Why this
inconsistency?

Because one is the RTL abstraction on the different OSes, the other one
is the direct Windows-API-Call.

Post by Sergei Gorelkin
Should I supply a patch that adds
Initialize/DeleteCriticalSection as aliases for
Init/DoneCriticalSection?

No, I'd suggest to fix your code.


Regards,

Vinzent.

[Sergei Gorelkin]

Post by Sergei Gorelkin
After
searching through RTL code, I discovered that abovementioned
functions are named InitCriticalSection and DoneCriticalSection. At
the same time, the EnterCriticalSection and LeaveCriticalSection are
not renamed, so code using them compiles without errors. Why this
inconsistency?

VH> Because one is the RTL abstraction on the different OSes, the other one
VH> is the direct Windows-API-Call.

But EnterCriticalSection/LeaveCriticalSection also exist in Windows API.
And they are implemented in System unit without changing names. Therefore, to
make my code cross-platform, I have only to remove Windows from uses clause -
then cross-platform versions from System unit will be used. This is
fine.

Contrary, InitlalizeCriticalSection and DeleteCriticalSection are
renamed. This makes me wonder. All four functions belong to a single
logical group and are being affected by whatever cross-platform issues in the
same way. One would expect that either all four
are renamed, or all four left with original names - this is the reason for my question.

[Micha Nelissen]

Post by Sergei Gorelkin
But EnterCriticalSection/LeaveCriticalSection also exist in Windows API.
And they are implemented in System unit without changing names. Therefore, to

They shouldn't be exposed publicly in the system unit.

Micha

[Vinzent Hoefler]

Post by Micha Nelissen

Post by Sergei Gorelkin
But EnterCriticalSection/LeaveCriticalSection also exist in Windows
API. And they are implemented in System unit without changing
names. Therefore, to

They shouldn't be exposed publicly in the system unit.

Why's that? At least it's documented that way. And I don't see any harm
in doing so.


Vinzent.

[Vinzent Hoefler]

Post by Sergei Gorelkin
But EnterCriticalSection/LeaveCriticalSection also exist in Windows
API. And they are implemented in System unit without changing names.
Therefore, to make my code cross-platform, I have only to remove
Windows from uses clause - then cross-platform versions from System
unit will be used. This is fine.

No. If you want to be cross-platform just do not use the "Windows" unit
at all. Rather only use the functionality provided by the system unit,
regardless of the compilation target.

The "Windows" unit should generally only included if you write platform
specific code and such code should be separated in its own include file
or even unit anyway.


Vinzent.

[Sergei Gorelkin]

Post by Sergei Gorelkin
But EnterCriticalSection/LeaveCriticalSection also exist in Windows
API. And they are implemented in System unit without changing names.
Therefore, to make my code cross-platform, I have only to remove
Windows from uses clause - then cross-platform versions from System
unit will be used. This is fine.

VH> No. If you want to be cross-platform just do not use the "Windows" unit
VH> at all. Rather only use the functionality provided by the system unit,
VH> regardless of the compilation target.

VH> The "Windows" unit should generally only included if you write platform
VH> specific code and such code should be separated in its own include file
VH> or even unit anyway.

That is exactly what I'm speaking about. Removing 'Windows' from
uses clause is essentially stopping using it :) And if the code
continues to compile and work after that, it is just fine.

The code I was compiling was already cross-platform (Delphi/Kylix),
and 'uses Windows' was wrapped by {$IFDEF MSWINDOWS}. In Kylix,
InitializeCriticalSection and DeleteCriticalSection are implemented in
SysUtils unit, so any code using these functions continue to work
under Linux. It was surprise for me that this code could not compile
with FPC.

[Luca Olivetti]

Post by Sergei Gorelkin
The code I was compiling was already cross-platform (Delphi/Kylix),
and 'uses Windows' was wrapped by {$IFDEF MSWINDOWS}. In Kylix,
InitializeCriticalSection and DeleteCriticalSection are implemented in
SysUtils unit, so any code using these functions continue to work
under Linux. It was surprise for me that this code could not compile
with FPC.

Any reason why not to use syncobjs? (I'm just curious, since that's the
unit I used when I needed critical sections).

Bye

[Vinzent Hoefler]

Post by Sergei Gorelkin
That is exactly what I'm speaking about. Removing 'Windows' from
uses clause is essentially stopping using it :) And if the code
continues to compile and work after that, it is just fine.

Sorry, I always forget that most people are not like me and just use
subroutine names without caring where they come from, while I'm used to
always prefix the unit names to the subroutines and thus simply
removing "Windows" from the use clause would not work, because the
routines suddenly come from a different place.

Well, my opinion and my experience say you should know which routines
you are actually using. I know that since the days I used DisposeStr
and the FPC compiled code horribly crashed, because it was the wrong
one.

Post by Sergei Gorelkin
The code I was compiling was already cross-platform (Delphi/Kylix),
and 'uses Windows' was wrapped by {$IFDEF MSWINDOWS}. In Kylix,
InitializeCriticalSection and DeleteCriticalSection are implemented
in SysUtils unit, so any code using these functions continue to work
under Linux. It was surprise for me that this code could not compile
with FPC.

I won't judge if FPC is correct here (it's supposed to be Delphi-, not
Kylix-compatible), but if Borland decided to move those routines, they
didn't do it right neither. ;)

Well, I'd still suggest to either stick to "System.InitCriticalSection"
etc. regardless if the Windows unit is included or not (yes, this
actually *requires* you to prefix it), or just use the SyncObjs unit
like everyone else out there.


Vinzent.

[Sergei Gorelkin]

Thursday, April 05, 2007, 11:45:34 AM, Vinzent wrote:

VH> Sorry, I always forget that most people are not like me and just use
VH> subroutine names without caring where they come from, while I'm used to
VH> always prefix the unit names to the subroutines and thus simply
VH> removing "Windows" from the use clause would not work, because the
VH> routines suddenly come from a different place.

VH> Well, my opinion and my experience say you should know which routines
VH> you are actually using. I know that since the days I used DisposeStr
VH> and the FPC compiled code horribly crashed, because it was the wrong
VH> one.

It appears that my way of thinking has been severely affected by using
IDEs. When putting mouse over identifier shows where it comes from, prefixing
seems redundant :)

VH> I won't judge if FPC is correct here (it's supposed to be Delphi-, not
VH> Kylix-compatible), but if Borland decided to move those routines, they
VH> didn't do it right neither. ;)

They did not move routines - they just had to implement Linux versions
somehow. And they did it in a way that was not breaking existing code.

VH> Well, I'd still suggest to either stick to "System.InitCriticalSection"
VH> etc. regardless if the Windows unit is included or not (yes, this
VH> actually *requires* you to prefix it), or just use the SyncObjs unit
VH> like everyone else out there.

In this particular case I wanted to avoid FCL dependence via using
SyncObjs.
Ok, for now I have it fixed. Since Ivo has a large patch pending, I shall
stay on...

[Vinzent Hoefler]

Post by Sergei Gorelkin
It appears that my way of thinking has been severely affected by
using IDEs. When putting mouse over identifier shows where it comes
from, prefixing seems redundant :)

Prefixing *is* redundant, that's the whole point of it, but it also
takes you to the safe side. I never liked Pascal's solution of calling
subroutines with the same name depending on the order of the use
clauses, when those use clauses are so far away from the actual code.
Change the clause, you (may) change the code.
Not mentioning this awful "reuse" clause here, that's the worst. But I'm
getting carried away... stop.

Well, so doing the mouseover to look at where it's from already has a
bad taste of suspecting some surprise.

And well, an IDE can't help you on the printout. Clicking on the
headlines in a newspaper doesn't take you to the article, neither. ;)

Post by Sergei Gorelkin
VH> I won't judge if FPC is correct here (it's supposed to be
Delphi-, not VH> Kylix-compatible), but if Borland decided to move
those routines, they VH> didn't do it right neither. ;)
They did not move routines - they just had to implement Linux
versions somehow. And they did it in a way that was not breaking
existing code.

So they should have implemented the "Windows" unit, simple as that. Or
add a "Linux" unit as replacement.

Post by Sergei Gorelkin
In this particular case I wanted to avoid FCL dependence via using
SyncObjs.

Fair enough. It's a reason after all.


Vinzent.

[Ivo Steinmann]

Post by Sergei Gorelkin
Hello,
I was porting to Linux some Windows code which uses critical
sections API, and got 'Identifier not found' error on InitializeCriticalSection and
DeleteCriticalSection symbols. After searching through RTL code, I
discovered that abovementioned functions are named InitCriticalSection
and DoneCriticalSection. At the same time, the EnterCriticalSection
and LeaveCriticalSection are not renamed, so code using them compiles
without errors. Why this inconsistency? Should I supply a patch that
adds Initialize/DeleteCriticalSection as aliases for
Init/DoneCriticalSection?
Regards,
Sergei
_______________________________________________
http://lists.freepascal.org/mailman/listinfo/fpc-devel

I reimplemented whole threading- and sync code in fpc RTL, including
Threadvars. My patch is very very big and need to be discussed in core
first. But all your problems will be solved.

I hope I can start the discussion on core soon, but I know it will be
endless. The user side of the RTL will 99% compatible to the old
version, but there's a complete reimplementation required for the
platfrom dependant code.

Just stay on...

-Ivo Steinmann