Re: Comedi and thread-safety

On Fri, 2005-03-04 at 15:43 +0000, Bernd Porr wrote:
> Well. I've programmed my driver so that it signals EBUSY while a command 
> is running or another situation arises which can be managed in parallel.
> 
> The trouble with USB is that the user can disconnect the device whenever 
> he/she wants. The order of events is quite unpredictable. Even with one 
> processor you have multithreading under 2.6.

Thanks for your answer. 
ATM I'm using a MC PCI-DAS6025 with the cb_pcidas64 driver. But I guess
all Comedi drivers behave similarly in this respect?


> Jan Gukelberger wrote:
> > These make me believe that I don't have to expect problems if I
> > serialise access to specific subdevices each with a mutex. (Use
> > pthread_mutex or comedi_lock()? Does comedi_lock() on a locked subdev
> > wait for the lock to be released or does it return EBUSY?) 

FWIW I've just dived into the Comedi source and here's what
comedi_lock() does: (comedi/comedi_fops.c:do_lock_ioctl())
-----------8<---------------------8<---------------------8<----------
	if(s->busy)
		return -EBUSY;

	comedi_spin_lock_irqsave(&big_comedi_lock, flags);

	if(s->lock && s->lock!=file){
		ret=-EACCES;
	}else{
		s->lock=file;
	}

	comedi_spin_unlock_irqrestore(&big_comedi_lock, flags);
-----------8<---------------------8<---------------------8<----------

AFAICT this means:
1) lock() returns EBUSY if subdev is busy. (When is that the case?)
2) lock() returns EACCES if subdev is locked by another process.
3) lock() does nothing if subdev is already locked by the same process.

Especially 3) renders comedi_lock() useless for thread synchronisation
(same process file) so I will have to use pthread_mutex for this
purpose.

Out of interest one question regarding above source: 
Why is s->busy checked before acquiring the spinlock? Doesn't this mean
that the subdev can be set into busy state by another process before
s->lock is set? Or can a subdev get busy even while another process is
holding the lock? In this case: Why is busy even checked by the LOCK
ioctl?

> > Parallel access to different subdevices should be all right. Right?
> > 
> > Or would it be even safe to e.g. comedi_read() one subdevice with
> > several threads in parallel? Probably not?
> > 
> > Oh, and one more question: What operations can be performed on a
> > subdevice while a comedi_command e.g. for recording is in progress?
> > 

Thanks,
Jan

Received on 2005-03-08Z13:15:16