Subj : Re: Lockable objects
To   : comp.programming.threads
From : Uenal Mutlu
Date : Fri May 20 2005 12:03 am

"doug" wrote>
> "Uenal Mutlu" wrote in message
> > "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?
> >
> Erm...  <tumbleweed....> Yes.

Hmm. you don't seem to be very consistent, do you? Because just yesterday
you wrote the following:

"doug" wrote
> That's it, the end.  I'm out.  David bothered to read the code, I was
> laughing too hard after the second line.
>
> I just seriously hope that I never come across you in my professional
> career, or any of the code you've ever touched.  I will obviously now avoid
> Seimens mobile phones.

And you really expect me to answer your questions?

.