GLOBALMEM LOCK and UNLOCK question

[Vincent van der Leun]

Hi there,

I was wondering the following: Would it be an example of bad programming to do the following:

Execute GLOBALMEM ALLOC and GLOBALMEM LOCK in, say, a constructor of an object and keep the memory block "locked" for the lifetime of the object. And only do the corresponding GLOBALMEM UNLOCK (and GLOBALMEM FREE of course) when destroying the object?

I am guessing this is not the way we should work, but I was wondering why? C programmers, for instance, using malloc would only allocate memory and deallocate it, wouldn't they?

By the way, I always wanted GLOBALMEM-like features for PB but always thought we would not get them, because I thought they would think it would be too C-like... and so did never send my request in. This is probably the proof however that everybody SHOULD always send in their PB wishlists in to the PowerBASIC Inc. folks.

Best regards, Vincent

[Edwin Knoppert]

>By the way, I always wanted GLOBALMEM-like features

I wonder why?
I can name 2 or 3 reasons but barely related to PowerBASIC as feature.

[Michael Mattias]

You can lock it if you want.. which effectively creates the same object as malloc, a non-relocatable block of memory.

For that matter, it's what you get if you call GlobalAlloc () directly using the GMEM_FIXED flag.

If it's not relocatable you don't benefit from Windows' housekeeping. To the best of my knowledge no one has ever noticed. Except you WILL lose style points.

MCM

[Michael Mattias]

>>By the way, I always wanted GLOBALMEM-like features
>I wonder why?

Because absent the GLOBAL MEM xxx functions, the PowerBASIC compilers don't offer intrinsic functions to allocate a block of memory not subject to 'scope' concerns, other than using GLOBAL variables. And as an experienced maintainability-conscious programmer, you know GLOBALs not only make code less reusable, they also offer variable-name conflict opportunities; and you just don't want to go down that road.

(???)

MCM

[Edwin Knoppert]

No but why not provide an OLE string pointer?
Globals have afaik limited resources and if not created as pointer it has the overhead of being a handle which needs to be locked.

GlobalAlloc() is a bit obsolete except for native Windows API functions like common dialog stuff.

[Michael Mattias]

No but why not provide an OLE string pointer?
Globals have afaik limited resources and if not created as pointer it has the overhead of being a handle which needs to be locked.

GlobalAlloc() is a bit obsolete except for native Windows API functions like common dialog stuff.

GlobalAlloc() is a bit obsolete except for native Windows API functions like common dialog stuff.

SDK==>

Note The global functions are slower than other memory management functions and do not provide as many features. Therefore, new applications should use the heap functions. However, the global functions are still used with DDE, the clipboard functions, and OLE data objects.

I don't know from squat re "OLE Data Objects"

Everyone uses the clipboard.

Nobody uses DDE. (Except me, this week Monday as a matter of fact). (OK, so it was with some older software which only uses DDE, but it's still alive and kicking)

MCM

[Jeff Blakeney]

I was wondering the following: Would it be an example of bad programming to do the following:

Execute GLOBALMEM ALLOC and GLOBALMEM LOCK in, say, a constructor of an object and keep the memory block "locked" for the lifetime of the object. And only do the corresponding GLOBALMEM UNLOCK (and GLOBALMEM FREE of course) when destroying the object?

I am guessing this is not the way we should work, but I was wondering why? C programmers, for instance, using malloc would only allocate memory and deallocate it, wouldn't they?

You only need to lock the memory when you want to access it. The only way a program that uses your object can access that memory is if you give them the handle to that memory or they use one of the methods of your object to affect that memory somehow. Giving the calling program full access to the memory allocated by the object kind of defeats the encapsulation benefit of an object so would probably be a bad idea.

It seems pretty simple to me to do a GLOBALMEM LOCK and UNLOCK in methods that deal with that memory whether they are called from outside your object or from other methods inside your object. Like Michael said, by doing this you also benefit from Windows' housekeeping.

So overall I would say it would be bad, as well as lazy, programming style to simply lock the memory and leave it that way. The only time I could see leaving it locked is if it is being accessed a lot and the locking/unlocking starts to become a performance issue. For example, I've been toying with the idea of writing an Apple IIgs emulator with PB but because I would be accessing the memory constantly to get the next instruction and operand, modify memory based on that command and constantly updating certain memory locations for I/O and reading the display memory so it can be shown in a window, I would probably leave the memory locked for the duration of the program.

By the way, I always wanted GLOBALMEM-like features for PB but always thought we would not get them, because I thought they would think it would be too C-like... and so did never send my request in. This is probably the proof however that everybody SHOULD always send in their PB wishlists in to the PowerBASIC Inc. folks.

There are other ways to get chunks of memory but these commands are pretty handy.

[Michael Mattias]

>So overall I would say it would be bad, as well as lazy, programming style ...

That's what I wanted to say. But nobody likes it when I use words like "bad" or "lazy" in any context in which someone would have a chance to take it personally.

So I settled for, "Except you WILL lose style points"

[Edwin Knoppert]

I just didn't get an answer from the OP.

Imo this way of allocation came from a perspective that any memory not being locked could be swapped to disk.
This has all been changed but Windows needs to be backward compatible and some parts just need these handles.

I don't see any purpose for handles for memory any longer for daily programming.
A simple string pointer (like OLE strings/SysAlloc...) would do fine.

I just wonder'd why someone wants the overhead of handles and why PB choose to implement this older allocation technique.
The few functions which needs a HGLOBAL can be dealt with using plain API calls.
They are simple enough.
Locking and unlocking may only bring more confusion.

OK, let's hear it..

[Michael Mattias]

Imo this way of allocation came from a perspective that any memory not being locked could be swapped to disk.

Um, that is not what it means at all.

When you LOCK a global handle, it means the virtual address (pointer) of the data will not change while it remains locked. There are no guarantees that it won't be swapped into the page file if space is needed for something else; but you will be guaranteed when it is swapped back in that data will still be at that virtual address.

We also don't know that GLOBAL MEM ALLOC et al are actually implemented using the GlobalAlloc() functions. I strongly suspect so, and I'm sure someone could disassemble a program to find out for sure.

But even finding this out is no guarantee the internal implementation of the GLOBAL MEM ALLOC statement would not change in another version of the compiler.

I guess then I need to qualify my statements above re virtual address: those DO apply to the Windows GlobalAlloc() family of functions. I do not know how GLOBAL MEM LOCK is implemented in the compiler nor what it means vis-a-vis page file use.

[Vincent van der Leun]

>By the way, I always wanted GLOBALMEM-like features

I wonder why?
I can name 2 or 3 reasons but barely related to PowerBASIC as feature.

Perhaps I should have been a bit more clear, I meant I wanted memory allocation routines in general. Before I upgraded to PB/Win 9 I used global dynamic string variables to store non-string data and I didn't really like that approach personally. I think when a language has a full pointer implementation, memory allocation is very useful.

Right now I am developing an application that uses classes which internally use GLOBALMEM statements to store certain data. As it's a graphical intensive program every statement that I can lose in the frame-update routine is probably welcome.
For the moment I still "LOCK" and "UNLOCK" the memory blocks, I will worry about optimalization later. I am clearly still in the early test phase anyway.

I was mostly wondering why C programmers don't have to worry about locking and unlocking and what would be the possible side-effect when memory stays locked for a potentially long time.

Still, at this time I plan to not lose style points for this :silvercup:

Thanks everybody for their input so far!

[jcfuller]

My turn.
I've always used the heap functions for my memory allocations.
GlobalAlloc uses the local/global heap and you may end up with fragmentation of the heap and for all i know this might cause the swapping of data to the disk?
Creating your own heap you have the luxury of destroying it and start over if need be.

Jame

[Michael Mattias]

I was mostly wondering why C programmers don't have to worry about locking and unlocking

I would guess it's because C programmers generally allocate memory using malloc, which 'by definition' returns a pointer which remains valid untile free() or realloc() is called; fom this we can infer the C-compiler publisher is implementing malloc using either GlobalAlloc()+GlobalLock() or HeapAlloc(), both of which result in an unmoveable block of memory.

FWIW: malloc, realloc, free for PB/Win32 September 20, 2002

Also, you might want to take a peek at the GlobalAllocPtr macro sometimes used n c programs. Looks a lot like it's PB counterpart would look:

MACRO GlobalAllocPtr (size) = GlobalLock (GlobalAlloc (%GHND, size))