Think about atomicity: You look with fstat or something like that. You find that nobody is accessing it right now. So you start. What if somebody else is doing exactly the same thing at the same time? This approach doesn't really work reliably.
The other question is this: Who is this other program that might be using the same hardware? Is it your own program, so you control both source code stacks? Is the device accessed as a /dev/xxx file? If yes, that opens some avenues. For example: If all the programs that use this hardware can be modified so they use exclusive locking (the O_EXLOCK flag when opening), then you can cause all other open attempts to fail or block. But since this type of locking is "advisory", it only works if all the programs that use the device use locking; even when the device is locked by your program, a normal program can just open() the device and do IO. If locking on the actual device file /dev/XX doesn't work, you could modify all your programs to use a sentinel file nearby; for example, when they want to use the device, they first create /tmp/dev_XX_is_open and lock it. AFAIK, you can not enable mandatory locking on the device file system, so that's out.
If the device is a serial port (of type /dev/ttyXX), then there is a well-known protocol involving lock files that nearly all programs that use serial ports will follow; in effect, this makes the advisory locking de-facto mandatory. But you said webcam, and that's probably not a serial port.
I don't know of a general solution that works against all programs, without using non-standard OS extensions that make locking mandatory. I don't know that FreeBSD has those, in particular not on the device file system.
