Subj : Re: Lockable objects
To   : comp.programming.threads
From : Uenal Mutlu
Date : Thu May 19 2005 11:48 pm

"doug" wrote
>
> "Sergei Organov"  wrote in message
> > "Uenal Mutlu" writes:
> >> A mutex can be realized in just 8 bytes (counter and threadid).
> >> These methods would be like any other method of the object:
> >> just use which you want/need/like, or don't use at all: you have the
> >> choice.
> >
> > Didn't you forget to attach a condvar to every non-trivial object as
> > well? Just imagine how useful it is to have it ready for signalling and
> > for waiting for changes to the object!
> >
> >> The advantage of having such an "architecture" in the language
> >> gives far more possibilities for the users.
> >
> > ... and then we end up with a "class Everything" that provides all the
> > imaginable possibilities to the user, including automated check against
> > famous Uenal Mutlu deadlock theorem. We have reached ultimate
> > perfectness! Congratulations! The only problem is that it seems that
> > nobody but Uenal Mutlu will use the language then.
> >
> >> And: multithreading has become a de facto standard in programming,
> >> esp. in application programming.
> >
> > ... mostly due to the fact that one famous OS doesn't provide a sensible
> > way to deal with non-trivial IO without threads and has pure support for
> > processes, IMHO. Hard times during which programmers learn *not to use
> > threads* where they are inappropriate I foresee :(
> >
> > --
> > Sergei.
>
> I imagine someone's just finished the latest chapter in their threading
> book.  However, it doesn't look like he's actually *ready*, just skimming.
>
> So here's some random babbling.  I don't see why i should bother to
> formulate my points properly, if a) you don't respond to them, and b) your
> postings aren't just random, their plain nonsense!
> - why 8 bytes?  Is that just because that's what your current OS uses?  what
> about other systems?  what about things like alignment?  especially on SMP
> systems?
> - counter and thread id.  Didn't you forget the actual lock itself?
> - what use is GetLockedCount() or IsLocked()?  (Unless it's for
> debugging/diagnostics).  When called by the non-owner, they're unreliable,
> and there's no reason an owner should need to call these.  Providing them
> just promotes extremely poor design.
> - what about timed acquires?
> - you've forgotten about signal semaphores/condition variables.  It's likely
> you don't know what these are.
> - what about single-writer, multi-read locks?
> - finally, recursive mutexes.  No, no, no, no, no.  Especially, with
> multi-cores becoming common, if you write multi-threaded programs, a
> recursive lock (as others have pointed out to you), serves one and only one
> purpose - the ability to put a bottleneck in your program.  (Maybe two - the
> abliity to hide bugs until your customer runs the code.)

Are these questions directed to me?

.