cron is always running -- it's a daemon. When it starts (at boot-up), it looks for crontab files in a specific directory, reads all the ones that are present, and sets "alarm" signals for when the various jobs are supposed to run. The files are organized by user; root always has a crontab file, and it's up to the sysadmin to decide whether other users can have their own crontabs as well.

There's a specific unix command called "crontab" that you run to view or edit the crontab file; if you say "crontab -e" to edit it, your default editor is invoked on a copy of your existing crontab file (or on a new file, if you never used cron before), and when you exit the editor, the "crontab" utility takes over again -- it replaces the original file with the edited copy, and sends a signal to the cron daemon that will cause cron to re-initialize based on the updated file. If you added a command to your crontab file that is supposed to run at noon every day, and you close the editor 30 seconds after noon, the command won't run till tomorrow.

Most problems are avoided by keeping crontab files separated by user. Of course, on unix, a single user can be running a number of command-line shells at once, and could try to edit the same crontab file from two separate shells (this is quite possible, e.g. when two or more people, working in different locations, can log in as root); but "crontab -e" uses flock, and will not allow concurrent edits of the file.