Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Aug 2000 11:34:55 +0200
From:      Jonas Bulow <jonas.bulow@servicefactory.se>
To:        hackers@FreeBSD.ORG
Subject:   Re: IPC, shared memory, syncronization AND threads...
Message-ID:  <3997BD3E.2B65AD19@servicefactory.se>
References:  <39943C37.76D2DBCC@servicefactory.se> <39948331.5E83DE1B@servicefactory.se> <200008120230.TAA60410@vashon.polstra.com> <3995431A.324F8C89@servicefactory.se> <200008121639.JAA63479@vashon.polstra.com>

next in thread | previous in thread | raw e-mail | index | archive | help
John Polstra wrote:
> Jonas Bulow wrote
> > Maybe I havn't been thinking enough but wouldn't this lock mechanism
> > be a good choice to use for mmaped:memory accessed by multiple
> > processes?
> 
> It depends on the amount of contention you expect.  The code in
> lockdflt.c was designed for a very low-contention situation (usually
> no contention at all).  It also had to work in a very restrictive
> environment where the threads package was unknown and could be
> practically anything.  Also it was designed to do locking between two
> threads running in the same process, which is not the problem you're
> trying to solve.  Your environment is much more controlled, so you can
> probably do better.

I think I'm trying to solve the threading-problem too. The overall
architecture is a preforked server where there is a need to share
information between all threads in all preforked processes. The solution
below seems to be good if flock doesn't block all threads in a process,
that is.

> 
> I think the ideal solution would first try to lock the test-and-set
> lock, maybe spinning on it just a few times.  If that failed it would
> fall back to using a system-call lock such as flock() which would
> allow the process to block without spinning.  But I don't have any
> code to do that.  (If you write some, could I have a copy?)

I am about to. I don't know it it's bad design to have rtld.c export
lockdflt_init in the same way as dlopen, what di you think?

/jonas


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3997BD3E.2B65AD19>