Kevin Stallard <kevin@fffflyingrobbbotsss.com> wrote:
Hi,
I’d like to have the OCB locked instead of the attribute structure in my
resource manager. It seems that since the same attribute structure is
shared by whom ever connects to the same “file”, they are prevented from
running cuncurrently. Since the OCB is the only thing that gets modified
during an actual read or write operation (or is it?), wouldn’t it be safe to
lock it instead of the attribute struct, allowing these clients to run in
parallel, if they all issued seperate open()'s on the same mountpoint?
Also, if the attribute sturct still needs a lock, it seems that a shared
lock on the attribute structure (pthread_rwlock_*()) would be preferable to
an exclusive one.
Normally stuff in the attribute structure gets modified as well.
But, that isn’t the main reason. The idea is it is a file, and
operations to a file MUST be ordered, because a write() [up to a
certain size] is defined to be an atomic operation – so it must
all go through to the underlying file (whatever that means, but
think of a file on disk for understanding) complete.
Also, some of the things that may get updated in the attribute
structure may include file size, access times, etc.
Even worse, if you’re using the attribute structure to represent
underlieing hardware, e.g. a UART, and you don’t lock the attribute
structure, you may have two different threads trying to access the
same hardware at the same time – this is (almost) always a BAD
thing.
Or, if you have a queue or buffer associated with the hardware, this
again will generally be stored off the attribute structure, and locking
the attribute structure will also lock access to the queue/buffer as
well.
Is it OK to ignore the RSVD in IO_RSVD_OCB_LOCK and provide OCB locking
instead of the default iofunc_attr_lock()? I’m not as experienced as I’d
like to be with resmgrs and any reasons as to why this wouldn’t be such a
good idea, would be appreciated.
So, I would generally suggest sticking with attribute based locking.
In general, this means if you have a single-device resource manager,
there is (little to) no advantage to running the resource manager side
of things multi-threaded (e.g. with a thread pool) though there may still
be some advantage to having threads, for instance a hw interupt servicing
thread.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.