Latches
Latches are very lightweight, short-term synchronization objects protecting actions that need not be locked for the life of a transaction.
When the relational engine is processing a query, each time a row is needed from a base table or index, the relational engine uses the OLE DB API to request that the storage engine return the row. While the storage engine is actively transferring the row to the relational engine, the storage engine must ensure that no other task modifies either the contents of the row or certain page structures such as the page offset table entry locating the row being read. The storage engine does this by acquiring a latch, transferring the row in memory to the relational engine, and then releasing the latch.
While locks protect data during transactions, another process, latching, controls access to physical pages. Latches are very lightweight, short-term synchronization objects protecting actions that do not need to be locked for the life of a transaction. When the engine scans a page, it latches the page, reads the row, gives it back to the relational engine, and then unlatches the page again so another process can reach the same data. Through a process called lazy latching, the storage engine optimizes access to the data pages by releasing latches only when a page is also requested by another ongoing process. If no ongoing process requests the same data page, a single latch remains valid for the entire operation on that page.
AWE
In SQL Server 2005 memory allocation is by default dynamic, even when AWE is enabled. AWE is applicable on 32 bit operating systems The AWE (Advanced Windowing Extensions) API allows applications to access more than 4GB of RAM. The exception to this is when running SQL Server 2005 on windows 2000 32 bit operating system with AWE enabled; in this case memory allocation is static. AWE support is only available for STANDARD, ENTERPRISE and DEVELOPER editions of SQL Server.