* Lennart Poettering <[email protected]> [2010-07-06 15:45:26]:
> On Tue, 06.07.10 09:33, Balbir Singh ([email protected]) wrote:
>
> > ABBA is a good point, it imposes lock ordering across all locks we
> > have, not something we desire. However, I've been wonder how glibc
> > handles all of this and provides thread safe functions.
> >
> > You might wonder why I want to have the locking around, there are
> > three points
> >
> > 1. Application level serialization is more coarse than library level
>
> Neither do I see why that would be the case, nor do I see why that would
> be a problem. Are you afraid of performance issues?
>
> Well, if you remove the locks, and people can instantiate an independent
> context for each of their worker threads all locks would go away, and
> things would be even faster!
>
> That said, this stuff is in no way relevant for perfomance. Nobody uses
> this stuff in inner loops, so perfomance simply doesn't matter.
>
Beyond performance, there is also latency. I agree with you in
general
> > 2. I am concerned about changing applications that rely on the
> > library locking behaviour, most applications live within libcg
> > source base, but still I'd like to not break outside applications.
>
> You are creating more problems with this than you are solving.
>
Why do you say so? I am thinking of the fraction of users that create
threads and fork()/exec() from a thread versus just using the API and
not worrying about concurrency at all. So we force them to rewrite
their code? If we have a working pthread_atfork() solution guaranteed
to work correctly, would you still feel this way?
> > 3. Thread based fork() -> exec() is a special scenario and currently
> > our locks are not strongly ordered, so we'll need to review/monitor
> > addition of new locks. The cgroup_mount_table_lock and rl_lock
> > have no strong dependency, the current solution posted should
> > work, ideally.
>
> I'd just remove them. Less problems to think about. Faster. Easier. And
> just 200% more awesome.
>
> Userspace programmers who use low-level APIs like this one tend to know
> the locking problems quite well. There's not need in trying to outsmart
> them and provide locking in the library, assuming that the users weren't
> as good at this as you are.
>
I believe that most users are really smart, no doubt about that.
--
Three Cheers,
Balbir
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Libcg-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libcg-devel
