Anders Melander

Then you shouldn't have mentioned it. If you post something as an example of a lock free implementation and it's clearly not thread safe, then I think it's fair that people are warned about that fact.

You have a problem so you decide to use threads. you problems.2 have Now

If you can live with FIFO LIFO/FILO/stack semantics then you can use Windows SLists. They're lock free and can be used with multiple readers and writers.

There's at least one race condition. Stopped reading once I spotted it: if InterlockedDecrement(FActiveWriters) = 0 then FActiveWritersZeroEvent.SetEvent;

MadExcept: Main thread freeze checking http://help.madshi.net/HowToUseMadExcept.htm

I'd recommend SVN or GIT - and since someone dared to mention it, I'd also like to warn against TFS. It's an abomination and just a tiny improvement over VSS. In my experience the learning curve, if coming from VSS, is much smaller for SVN than for GIT. IMO the DVCS aspect of GIT is mostly hype since nobody uses it that way, but it does make it easy to work with local feature branches. If you need your source hosted in the cloud I think GIT is the best solution. There are SVN hosting solutions but in my experience they aren't very good. I personally prefer SVN as it matches the way I think better. I do use GIT but I really have to think hard about what I'm doing every time I need to do something with it. I can picture what I want to do in my head but have a hard time translating that to the available actions. For SVN I use TortoiseSVN and for GIT TortoiseGIT. I also have SourceTree v1 (v2 is a bad joke) but it's really slow to work with - and buggy. I didn't know there was a newer version, so I'll check that out.

I believe this was addressed recently in Graphics32: TBitmap32 constructor access violation FWIW @Shrinavat you should have been able to determine the cause of the AV on your own by just looking at the call stack in the debugger. If this is beyond you then multi threading is not for you.

Here's how I would solve it - in theory: Assign each tile a sequential number. Since you know the size of the target bitmap (TargetSizeX*TargetSizeY) and you know the size of each tile (TileSizeX*TileSizeY), calculating the tile number is simple: TileCountX := ((TargetSizeX + TileSizeX-1) div TileSizeX); TileCountY := ((TargetSizeY + TileSizeY-1) div TileSizeY); TileCount := TileCountX * TileCountY; // Tile number goes from 0 to TileCount-1 // Tile coords from Tile number TileX := (TileNumber mod TileCountX) * TileSizeX; TileY := (TileNumber div TileCountY) * TileSizeY; The job of reading a tile from the database can be delegated to one or more tasks, depending on how you choose to partition the workload. A DB tasks reads a request from a (threadsafe) queue, performs the database request, stores the result in the request object and notifies the requestor that the result is ready. The request object contains: 1) Tile number, 2) Result bitmap and 3) Signal object (e.g. an event handle). Create a number of tasks to render the tiles. Each task grabs a Tile Number (just use a InterlockedIncrement() on a shared integer), creates a DB request object, queues it and waits for the result. Once the result is ready the task draws the tile onto the target bitmap (*) and starts over. To avoid cache conflicts it would be best if the Tile Numbers currently being worked on are as far apart as possible, but I guess the DB overhead will make this optimization irrelevant. *) A TBitmap32 is just a chunk of sequential memory and since none of the tile tasks will write to the same memory it is not necessary to lock the target bitmap. So in short: One thread pool to render the tiles and one thread pool to read from the database. A work queue in between them. However like @Cristian Peța said, unless you are using some super fast ninja science fiction database, there's no reason to try to optime the rendering much. All the tiles can probably be rendered in the time it takes to make a single database request. In fact, using graphics32, a thread context switch will take far longer that drawing a single tile. So in practice I would probably just do away with the DB tasks and execute the database request directly from the rendering tasks.

Not possible. Only the resource ID, type and content is stored in the executable. In other words: After a resource has been linked into an application there's no way of knowing where it came from.

Hey, good idea: https://github.com/DelphiPraxis/The-Drag-and-Drop-Component-Suite-for-Delphi

For a minimal setup to use TFSV I suggest you use Team Explorer. It's basically just the VS shell with the TFS plugin. Here's the download: https://visualstudio.microsoft.com/thank-you-downloading-visual-studio/?sku=TeamExplorer&rel=15# And here's a brief intro of how to use it: https://docs.microsoft.com/en-us/azure/devops/user-guide/work-team-explorer?view=vsts @David Schwartz TFSV has always supported branching. It just isn't very good at it - like everything else in TFS. We use TFS with TFSV where I work ATM but I would gladly pay for JIRA licenses out of my own pocket if that would get them to switch away from TFS. It's horrible.