L4Re: region mapper/manager concurrency considerations and resource limits

Paul Boddie <[email protected]>
Newsgroups gmane.comp.micro-kernel.l4.devel
Message-ID <1963793.pUpih6h91s@jason>
Hello,

Apologies for introducing two potentially separate topics, but they both seem 
to present themselves in my most recent endeavour. In short, I am wondering 
about the following...

What considerations need to be given to concurrency with regard to the use of 
the l4re_rm_attach function and similar functionality? Is access to the region 
mapper/manager from different threads in the same task advisable, are there 
thread safety issues, and if so, can these be sensibly worked around?

(I have observed what seems to be the same address being provided for two 
different dataspaces at the same time, which does not appear to happen when I 
introduce locking around calls to l4re_rm_attach. Are such problems expected 
or could this be some other problem manifesting itself?)

What kind of resource limits apply to L4Re tasks? In my work, I am allocating 
capabilities for objects acting as dataspaces. Things seem to work fairly well 
up to a certain point, and then capability allocation seems to fail, and 
program failure is then not particularly graceful.

(I currently observe that creating 160 threads, each with its own IPC gate 
capability seems to be unproblematic, but more than this will produce errors 
that manifest themselves either in pthread library code or in my own code 
where a critical section is supposed to be enforced.)

I suppose some contextual remarks might be useful. My previous work involved 
providing some simple filesystem-related functionality through filesystem 
servers, where a new server object (exposed via an IPC gate and having its own 
thread) is created for each open file. Some stress testing in a multiprocessor 
environment indicated that various concurrency issues were highly likely to be 
present.

(I also probably didn't provide general enough support for flexpages, but 
since all my "send" flexpages were single machine pages, I don't think this 
would have caused additional problems or confusion.)

Consequently, I migrated the principal mechanisms to my Linux environment and 
wrote a simulation to explore the concurrency situation, identifying and 
hopefully remedying various deficiencies (including more general flexpage 
support). This new endeavour involves bringing this tested functionality back 
into L4Re, wiring it up with the IPC system, and testing using multithreaded 
clients.

I might also ask about support in L4Re for C++ threading constructs. When 
developing my simulation, I decided to use the standard C++ support for 
threading, mutexes, condition variables, and so on, as opposed to using 
pthread functionality. I imagine that C++ library support for these things 
just wraps the pthread functionality, but I wonder if there are not other 
considerations that I might need to be aware of.

Sorry if this is in any way vague, but since there isn't really any discussion 
about system architecture or implementation on this list with respect to these 
technologies (or really any technologies), I find myself experimenting with 
the available software to determine techniques and approaches that I hope will 
be viable. Nevertheless, any constructive remarks or advice would be greatly 
appreciated.

Thanks in advance,

Paul
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.