Yes, but as I mentioned, this is not necessary specifically only with InnoDB. Because it writes to disk atomically, you will get a valid point-in-time copy of the database simply by taking a filesystem snapshot; no read lock required, which means the application can continue operating from the user's perspective.
The problem with a read lock is that, if done on a master DB, you will impact the production service that uses the database. Depending on the workload, this could take a minute or even longer, which is usually not acceptable.
However, there's another problem: MySQL performance degrades significantly on LVM when a snapshot is active. So even though the database continues operating as usual, performance will not be the same (and perhaps not at all adequate) during the backup period -- especially considering that you're doing extra disk I/O to get the data copied off.
So, I prefer to use xtrabackup these days. This presumes that you have no MyISAM tables though; otherwise you're back to mysqldump or taking a read lock or some other less desirable method.
One other point: if you backup with filesystem snapshots (of the raw DB files), then you have to restore the entire database during a restore. Maybe this is fine and maybe it's a huge headache.
There are a million ways to backup MySQL (and other DB's), and it really comes down to what kind of downtime you can tolerate during your backup. I generally want to back up very frequently, without impacting the service, and avoiding replication (and all of the headaches involved in that -- see the existence of tools like mk-table-sync for an idea of what can go wrong) if possible. If you don't have those requirements, then mysqldump or mylvmbackup or something else are totally valid options.