Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/Multithreaded resource manager/List of Posts
Forum Topic - Multithreaded resource manager: (5 Items)
   
Update
bob lipka
07/09/2008 6:25 AM
post10215
Multithreaded resource manager   
I have compiled multithreaded resource manager with io_write and io_read procedures, made form code snippets cut exactly
 form Neutrino programmers guide. For testing I have added printfs at the beginning of io_read and io_write, with 
sleep(10) after each printf. I attach the source.

I was hoping, that if my write blocks for 10 seconds I still be able to read and vice versa, but it does not work like 
this. When one i/o blocks and the other is issued then its thread starts, but blocks on some CONDVAR not even reaching 
its io_xxxx function. It gets there only after this first thread unblocks from nanosleep and finishes.

What should I do to have this multitheading work simultaneously, not one after another?

RobertL
Attachment: Text rmmtrw.c 5.77 KB
Thomas Haupt
07/09/2008 7:12 AM
post10216
AW: Multithreaded resource manager   
You'll need to unlock the I/O attribute structure in the OCB 
during the 'inactive' period (i.e., while sleeping).

The attribute structure is implicitly locked before entering 
and unlocked after leaving your handler functions (at least, 
for most of them). This is to automatically ensure only one 
thread will access a device at a time.

So while in io_write, your attribute structure is locked -- 
and the framework tries to aqcuire that lock before entering 
io_read, thus getting blocked on a condvar. 

To get around this, unlock the attribute structure before 
sleeping, and re-lock it when getting busy again:

   iofunc_attr_unlock( ocb->attr );
   ...sleep...
   iofunc_attr_lock( ocb->attr );

- Thomas

> -----Ursprungliche Nachricht-----
> Von: bob lipka [mailto:bobik@os.pl]
> Gesendet: 09 July 2008 12:25
> An: ostech-core_os
> Betreff: Multithreaded resource manager
> 
> 
> I have compiled multithreaded resource manager with io_write 
> and io_read procedures, made form code snippets cut exactly 
> form Neutrino programmers guide. For testing I have added 
> printfs at the beginning of io_read and io_write, with 
> sleep(10) after each printf. I attach the source.
> 
> I was hoping, that if my write blocks for 10 seconds I still 
> be able to read and vice versa, but it does not work like 
> this. When one i/o blocks and the other is issued then its 
> thread starts, but blocks on some CONDVAR not even reaching 
> its io_xxxx function. It gets there only after this first 
> thread unblocks from nanosleep and finishes.
> 
> What should I do to have this multitheading work 
> simultaneously, not one after another?
> 
> RobertL
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post10215
>
bob lipka
07/09/2008 7:38 AM
post10218
Re: AW: Multithreaded resource manager   
> The attribute structure is implicitly locked before entering 
> and unlocked after leaving your handler functions (at least, 
> for most of them). This is to automatically ensure only one 
> thread will access a device at a time.

Is it safe then to one thread write only and another read only in the same time, provided I write MY OWN pieces of code 
thread-safe?

RobertL
Thomas Haupt
07/09/2008 8:06 AM
post10220
AW: AW: Multithreaded resource manager   
In general, I wouldn't really recommend doing this - remember,
if you "shortcut" the lock in your io handler code, this will 
give other threads a chance to alter the states of the device 
and/or the ocb while the handler is sleeping...

You ought to be fine as long as...
...the unlocked delay occurs at the very beginning of the handler 
   function, and
...you only 'parallelize' read and write. I wouldn't take chances 
   on, e.g., closing a file while reading it... guess that'd leave 
   your read handler with an invalid ocb...

In other words, you need to make sure that neither the handler's 
parameters nor the ocb/device data will turn stale during the 
unlocked phase.

Regards,
- Thomas

> -----Ursprungliche Nachricht-----
> Von: bob lipka [mailto:bobik@os.pl]
> Gesendet: 09 July 2008 13:38
> An: ostech-core_os
> Betreff: Re: AW: Multithreaded resource manager
> 
> 
> > The attribute structure is implicitly locked before entering 
> > and unlocked after leaving your handler functions (at least, 
> > for most of them). This is to automatically ensure only one 
> > thread will access a device at a time.
> 
> Is it safe then to one thread write only and another read 
> only in the same time, provided I write MY OWN pieces of code 
> thread-safe?
> 
> RobertL
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post10218
> 
>
bob lipka
07/09/2008 9:23 AM
post10225
Re: AW: AW: Multithreaded resource manager   
> In general, I wouldn't really recommend doing this - remember,
> if you "shortcut" the lock in your io handler code, this will 
> give other threads a chance to alter the states of the device 
> and/or the ocb while the handler is sleeping...

My handler of course will not merely sleep at the beginning, it will do read/write over blocking socket somewhere later 
down in the handler functions.
I think that I at least will try this approach, since client using my device uses only simple open-read loop-close and 
open-write loop-close sequences in separate threads having separate fd handles for each direction of data flow. This 
implies separate OCB's in resmgr as I understand. 

Thank you very much for your advice. 
RobertL

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems