Re: Comedi and thread-safety

> > > 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.

It should probably return an error if its already locked by the same 
process, since it doesn't do any reference counting.

> > 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?

It looks like a bug.  You know, the big_comedi_lock only matters if you are 
using kcomedilib.  Ordinary user-space processes will already be holding 
the big kernel lock when inside an ioctl anyways.

-- 
Frank