I'll take a shot at this, the "Atomic load" of the policy on the gateway is also called the "commit" in some of Check Point's other documentation. The term atomic in computer science means a non-interruptible operation that cannot ever be preempted by something else; other elements (drivers, programs, packets being routed, etc) of a system "see" the atomic operation appearing to complete instantaneously since they cannot interrupt it. I assume in the case of a policy load this term means no packets can move through the firewall and must be queued while the atomic policy load is in progress. The sequence according to my understanding:
1) After the gateway successfully receives the compiled policy via CPTA, it performs extra sanity checks on the compiled policy to ensure it is not about to push an invalid policy into the kernel which could be disastrous.
2) Once the sanity checks are complete, the atomic load begins and all traffic trying to pass through the gateway begins to queue and cannot pass while the atomic load is in progress.
3) The new policy is loaded into the INSPECT kernel instance(s) while traffic is still being queued; this process happens very quickly. Chain sequences which are viewable with fw ctl chain are rebuilt, and may end up adding or removing chain modules from the sequences if blades were enabled/disabled since the last policy push.
4) If enabled SecureXL is restarted as well and recalculates its various state tables based on the new policy (Edit: This restart of SecureXL is no longer necessary in R80.20+ due to the new F2V path introduced in that version). All security server daemons running on the gateway are notified of the new policy by fwd and adjust their behavior accordingly, which could include restarting, stopping (if a feature was disabled) or starting (if a new feature was enabled).
4) At this point if "Connection Persistence" is set to "Rematch connections" on the gateway object (the default setting), a CPU-intensive rematch of all open connections against the new policy is performed to ensure that all current connections are still allowed by the new policy. I'm not sure if this is performed in one big operation against all connections present in the connections table, or if it is performed packet-by-packet as they are released from the queues and forwarded, but this is where the atomic load ends one way or the other.
5) The rematch operation tends to be where the bulk of latency is encountered during a policy load, easily observable by a brief spike in latency if running a continuous ping. On an overloaded firewall if this rematch operation takes too long, the queues can overflow and packet loss occurs. RX-DRPs can occur as well during this period, due to the high CPU load incurred by the rematch process interfering with the timely emptying of interface ring buffers.
6) Once the rematch is complete, traffic flows normally.
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com
New 2-day Live "Max Power" Series Course Now Available:
"Gateway Performance Optimization R81.20" at maxpowerfirewalls.com