Why locking memory?

Lets suppose you have two threads running in your application. If these threads both access some global data structure and you want to make sure that only one of the threads can read/write this data at a time, you have to lock it. If you don't, this can result in unwanted and rather unpredictable results. Google for "thread" "mutex" and/or "race condition" will bring up tons of information on that.

Quote:

Original post by michaweyel Lets suppose you have two threads running in your application. If these threads both access some global data structure and you want to make sure that only one of the threads can read/write this data at a time, you have to lock it. If you don't, this can result in unwanted and rather unpredictable results. Google for "thread" "mutex" and/or "race condition" will bring up tons of information on that.

That's not what locking means in this context. Locking is the term used to ensure that a block of memory can be accessed. This may involve anything from doing nothing, providing a virtual address mapping to the physical memory location or even copying the data to an accessible region of memory (and then copying it back when it is unlocked).

If you are doing graphics, locking the surface prevents the videocard from moving the mempointer around.

This needs a bit of explanation:
Everytime you do some accessing to the videocard's memory you use a pointer to the memory surface. However, most videocards carry the actual memory around all over the place. If flip the primary and backbuffer on your videocard, it just grabs the memory pointer of both surfaces, and swaps them around(Much faster than a memcpy).

Thus, if you lock memory, you just put your foot on the pointer, so the videocard can't pick it up and move it around(For what reasons that might be). Once you got your foot on it(Locked), you can do whatever you want with it(Read, write, etc.) and when you are done, you remove your foot(Unlock) and the videocard can pick it up again and carry it around.

If you don't do this, and the videocard could have moved the memory to another location, you will get either weird video output(Which you can't predict or debug, since it's happening at random) or your game crashes.

Toolmaker

Quote:

Original post by Ichigo But what does it mean and how do I do it in C++?

Toolmaker's explanation gives the nuts and bolts description. At a high level, it means that you grab a pointer to the screen area in question (by calling Lock) which is yours and yours alone until you decide otherwise (by calling UnLock).

Most 2d APIs have this functionality built into their surface representation. Using one these APIs is the best solution when you need to do this. As you mentioned, SDL has the function inbuilt. In DirectDraw, you would call Surface.Lock (IDirectDrawSurface7.Lock? I use Managed DX currently, and can't remember the C++ prototype atm).

ld

In DOS-based 32bit games (Like those Allegro started off with), you had to lock memory if you wanted to use it in an interrupt.

An interrupt routine could be called at any time, and a page fault inside one will cause a crash - this would happen if the function or data structure had been swapped out. DJGPP supports virtual memory under DOS.

Therefore, if the region the interrupt routine was accessing was swapped out, the program would totally crash.

So that's why Allegro programs have LOCK_FUNCTION etc macros in, to prevent these things from being swapped out.

In protected mode OSs (For instance Windows or Linux) this doesn't matter at all, because you can't (in user-mode) create interrupt routines. The things that are done on DOS with interrupts are done on multitasking OSs by using other mechanisms (usually a background thread) which will cope even if the data or code are swapped out.

Mark

Quote:

Original post by markr Therefore, if the region the interrupt routine was accessing was swapped out, the program would totally crash.

Wouldn't that cause the whole system to crash too?