It's easiest to explain this by way of an example.

Say you've set up your syslog-ng to log to two files: /var/log/errors and
/var/log/messages. So you put the following in /etc/logrotate.conf: 

/var/log/messages /var/log/errors {
   weekly
   rotate 4
   compress
   # Don't use sharedscripts for initial example
   # sharedscripts
   postrotate
      /etc/init.d/syslog-ng reload >/dev/null 2>&1 || true
   endscript
}

When logrotate rotates the logs, it will do things in this order:

1. Rotate /var/log/messages (ie. rename messages -> messages.1; .1->.2 ...)
2. Run the /etc/init.d/syslog-ng reload 
3. Compress messages.1 -> messages.1.gz
4. Rotate /var/log/errors 
5. Run /etc/init.d/syslog-ng reload (again)
6. Compress errors.1 -> errors.1.gz

That's all fine. After step 1, syslog-ng still has an open fd to to the just-
renamed messages.1, and may still write to it. Step 2 causes syslog-ng to stop
writing to messages.1, and start writing to a new messages file. So it's safe
for Step 3 to compress messages.1, because it's no longer being written to.
Similarly for errors.log and steps 4,5,6.

Now somebody has noticed this isn't optimal, because we run syslog-ng reload
twice. So they've added the the sharedscripts option, to tell logrotate to
run the post rotate script only once, after the rotation occurs. Let's say we
uncomment the "# sharedscripts" in the logrotate.conf above. We now have
trouble, because the order of operations becomes:

1. Rotate /var/log/messages (rename messages -> messages.1 etc.)
2. Compress messages.1 -> messages.1.gz
3. Rotate /var/log/errors (rename errors -> errors.1 etc.)
4. Compress errors.1 -> errors.1.gz
5. Run /etc/init.d/syslog-ng reload

This means that both files are compressed while they may still be written to.
Any output to messages which occurs between step 2 and 5 will be lost. Any
output to errors Between step 4 and 5 will be lost.