corelinux-public — General discussions of CoreLinux++

Re: [Corelinux-public] Corelinux: bad name

[Frank V. C. <fr...@co...>]

Dan Kegel wrote:
> 
> "Frank V. Castellucci" wrote:
> > Dan Kegel wrote:
> > > The name 'CoreLinux'
> > > * Is boring
> > >    no originality, could have been named by a burocrat
> > > * Is too generic
> > >    'core' and 'linux' are highly overused terms
> > > * Is misleading
> > >    sounds like part of the Linux core, but it's not
> > > * Is presumptuous
> > >    you're trying to ride the coattails of the Linux name
> > > * Is uninformative
> > >    it doesn't describe the object-oriented nature of your package
> > >
> > > Suggestions:
> > > * make the name indicate object orientation, e.g. "CoreLinux++"
> >
> > Dan, maybe you should read the documentation. You will see it IS
> > CoreLinux++
> 
> Frank, did you read the following two steps in my suggestions?
> The name "CoreLinux++" is not a good name for your kit -- in fact,
> it shows a fair amount of hubris.

Lets put the name issue aside for the moment, I think the following is
more important...

> 
> > I agree, the classes in the module are just patterns. It is slow going
> > and I seem to be the only one moving on them, so it will continue to be
> > slow going. Semaphore is coming soon as will:
> >
> > Timers, Threads, Process, Memory Management, Module loaders,
> > SmartPointer, Reference, Signals, Directory and Name services, and yes
> > even more GoF patterns!
> >
> > and that is just the CORE library of things a C++ developer for Linux
> > will find useful.
> >
> > Then take a look as some of the framework requirements. Persist,
> > Application, Garbage Collection, Class loaders, Toolkits.
> 
> I still don't see anything specifically Linux-related there.  Posix-specific,
> maybe, but not Linux-specific.  You're limiting your audience.

Then tell me what it is that you would see as Linux related. This will
be constructive.

> 
> These *are* constructive suggestions.  I don't think I've made any
> invalid assertions (besides confusing the name of your mailing
> list with the name of your toolkit).
> 
> - Dan

Maybe not, as I said, lets put the name thing aside. I'd rather focus on
the Linux related issues. We can always change the name.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] Corelinux: bad name

[Dan K. <da...@al...>]

Rik Hemsley wrote:
> 
> #if Dan Kegel
> > I still don't see anything specifically Linux-related there.  Posix-specific,
> > maybe, but not Linux-specific.  You're limiting your audience.
> 
> IIRC, CoreLinux++ was to be optimised for Linux. It hasn't yet been,
> but that doesn't prevent that happening any day now...

So much of it looks like a general-purpose framework that
other OS folks may well decide to do the work to optimise
it under the hood for their own OS.

A few other problems with the name-

CoreLinux sounds like a distribution, or like a
book about the Linux kernel.  Searching for 'core linux'
yields http://www.amazon.com/exec/obidos/ASIN/1576104699

CoreLinux sounds like it's suitable for very low-level work --
but since it's in C++, you could never use it inside the
kernel.

CoreLinux sounds like something you *need* to write a Linux
program.  It isn't; you can write great Linux programs without it.

- Dan

Re: [Corelinux-public] Corelinux: bad name

[Rik H. <ri...@kd...>]

#if Dan Kegel
> I still don't see anything specifically Linux-related there.  Posix-specific,
> maybe, but not Linux-specific.  You're limiting your audience.

IIRC, CoreLinux++ was to be optimised for Linux. It hasn't yet been,
but that doesn't prevent that happening any day now...

Rik

-- 
Read provisionally.

Re: [Corelinux-public] Corelinux: bad name

[Dan K. <da...@al...>]

"Frank V. Castellucci" wrote:
> Dan Kegel wrote:
> > The name 'CoreLinux'
> > * Is boring
> >    no originality, could have been named by a burocrat
> > * Is too generic
> >    'core' and 'linux' are highly overused terms
> > * Is misleading
> >    sounds like part of the Linux core, but it's not
> > * Is presumptuous
> >    you're trying to ride the coattails of the Linux name
> > * Is uninformative
> >    it doesn't describe the object-oriented nature of your package
> >
> > Suggestions:
> > * make the name indicate object orientation, e.g. "CoreLinux++"
> 
> Dan, maybe you should read the documentation. You will see it IS
> CoreLinux++

Frank, did you read the following two steps in my suggestions?
The name "CoreLinux++" is not a good name for your kit -- in fact, 
it shows a fair amount of hubris. 
 
> I agree, the classes in the module are just patterns. It is slow going
> and I seem to be the only one moving on them, so it will continue to be
> slow going. Semaphore is coming soon as will:
> 
> Timers, Threads, Process, Memory Management, Module loaders,
> SmartPointer, Reference, Signals, Directory and Name services, and yes
> even more GoF patterns!
> 
> and that is just the CORE library of things a C++ developer for Linux
> will find useful.
> 
> Then take a look as some of the framework requirements. Persist,
> Application, Garbage Collection, Class loaders, Toolkits.

I still don't see anything specifically Linux-related there.  Posix-specific,
maybe, but not Linux-specific.  You're limiting your audience.

Since my first suggestion fell on deaf ears, let me restate them:

Suggestions:
* make the name (including the name of the mailing list) indicate object 
  orientation, e.g. "ObjectLinux"

* Be orginal: pick some word not normally associated with software,
  perhaps the name of an obscure city, county, dish, rock, or person
  significant to the people in the project,
  e.g. "LondonObjectLinux"
   
  This will make the package name more memorable and easier to
  find in search engines.
  
* If your package might reasonably be ported to other operating
  systems, don't use "Linux" in the name, e.g.
  "PosixObjectKit"

> I don't mind constructive opinions, but we are all (I assume) savvy
> enough to look at what has been said, and what is being done, before
> making assertions.

These *are* constructive suggestions.  I don't think I've made any
invalid assertions (besides confusing the name of your mailing
list with the name of your toolkit).

- Dan

Re: [Corelinux-public] Corelinux: bad name

[Joe N. <3ne...@pr...>]

> I agree, the classes in the module are just patterns. It is slow going
> and I seem to be the only one moving on them, so it will continue to be
> slow going. Semaphore is coming soon as will:

Ohhh, I feel guilty! I'd put muscle into corelinux if I wasn't running
my own project, Lightbulb. I know how you feel because sometimes I have
a very hard time getting anyone to even _respond_ to my plans. It's like
talking to a wall and it's one of the most frustrating things I can
think of. Anyway, I'll quit whining and get back to work... :}

Re: [Corelinux-public] Corelinux: bad name

[Frank V. C. <fr...@co...>]

Dan Kegel wrote:
> 
> The name 'CoreLinux'
> * Is boring
>    no originality, could have been named by a burocrat
> * Is too generic
>    'core' and 'linux' are highly overused terms
> * Is misleading
>    sounds like part of the Linux core, but it's not
> * Is presumptuous
>    you're trying to ride the coattails of the Linux name
> * Is uninformative
>    it doesn't describe the object-oriented nature of your package
> 
> Suggestions:
> * make the name indicate object orientation, e.g. "CoreLinux++"

Dan, maybe you should read the documentation. You will see it IS
CoreLinux++

> In fact, most of your classes don't seem to be particularly operating-system
> related; they look like they'd be useful anywhere.  For goodness' sake,
> pick a better name, please.

Dan, read the archives of the mailing list, or better yet, take a look
at the requirements forum. 

I agree, the classes in the module are just patterns. It is slow going
and I seem to be the only one moving on them, so it will continue to be
slow going. Semaphore is coming soon as will:

Timers, Threads, Process, Memory Management, Module loaders,
SmartPointer, Reference, Signals, Directory and Name services, and yes
even more GoF patterns!

and that is just the CORE library of things a C++ developer for Linux
will find useful. 

Then take a look as some of the framework requirements. Persist,
Application, Garbage Collection, Class loaders, Toolkits.

I don't mind constructive opinions, but we are all (I assume) savvy
enough to look at what has been said, and what is being done, before
making assertions.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] Corelinux: bad name

[Dan K. <da...@al...>]

The name 'CoreLinux' 
* Is boring
   no originality, could have been named by a burocrat
* Is too generic
   'core' and 'linux' are highly overused terms
* Is misleading
   sounds like part of the Linux core, but it's not
* Is presumptuous
   you're trying to ride the coattails of the Linux name
* Is uninformative
   it doesn't describe the object-oriented nature of your package

Suggestions:
* make the name indicate object orientation, e.g. "CoreLinux++"

* Be orginal: pick some word not normally associated with software,
  perhaps the name of an obscure city, county, dish, rock, or person
  significant to the people in the project,
  e.g. "GarnetCoreLinux++"
   
  This will make the package name more memorable and easier to
  find in search engines.
  
* If your package might reasonably be ported to other operating
  systems, don't use "Linux" in the name, e.g.
  "GarnetCore++"

In fact, most of your classes don't seem to be particularly operating-system
related; they look like they'd be useful anywhere.  For goodness' sake,
pick a better name, please.

- Dan

[Corelinux-public] Semaphore Design and Class Report

[Frank V. C. <fr...@co...>]

I checked in the INCOMPLETE design which includes most of the
AbstractSemaphore, MutexSemaphore, GatewaySemaphore, and Guard.

Please forgive me as I am attaching the Class Report (html) to this
message for those of you don't want to fuss with the model. You should
get a good idea of what is emerging. Focus on the libcorelinux package,
the others are analysis mostly.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] The rose smelleth

[Frank V. C. <fr...@co...>]

Ok,

MutexSemaphore, GatewaySemaphore, and EventSemaphore is what I will go
with in the design. The polls are still open if anyone wants to add
something.

Upon further thought, after originally stating Guard in the One-to-One,
a Guard is a Monitor.

Guard, in my view, is a specialized MutexSemaphore. A few differences I
see:

1. Guards shall be locked upon creation.
2. You can't take the address of a Guard, it exists as automatic in
scope.
3. Guards that go out of scope shall be unlocked.
4. Guards shall not allow balk requests.
5. Guards shall not allow time out requests.
6. Guards shall not allow immediate return if unable to aquire.
7. Guards shall be unique and identified to a class.method.line level.
8. Guards shall not require a SemaphoreGroup from a implementators
perspective.

Any one?
 
-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] A rose by any other name...

[Jacob C. <jac...@ho...>]

my opinion(s):

>One-To-One Semaphores
>---------------------
>MutualExclusionSemaphore
  or
>MutexSemaphore



>One-To-Many Semaphore
>---------------------
>GatewaySemaphore



>Many-To-One Semaphores
>----------------------
>EventSemaphore

[Corelinux-public] A rose by any other name...

[Frank V. C. <fr...@co...>]

With my head in the One-to-One, Many-to-One, etc. stew I am trying to
capture that which best describes these types and is domain independent.
Although the current nomenclature would suffice for some (including me),
I don't feel they relay sufficient semantic information.

Please respond with opinions, arguments, flames, etc.

One-To-One Semaphores
---------------------
OneToOneSemaphore
GuardSemaphore
MutualExclusionSemaphore
MutuallyExclusiveSemaphore
MutexSemaphore
GateSemaphore
SynchronizedSemaphore

One-To-Many Semaphore
---------------------
OneToManySemaphore
MultiplexSemaphore
GatewaySemaphore
ServiceSemaphore

Many-To-One Semaphores
----------------------
ManyToOneSemaphore
EventSemaphore
TriggerSemaphore
BroadcastSemaphore
BroadcastEventSemaphore

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] Semaphore SRS, Use Case, Analysis

[Frank V. C. <fr...@co...>]

Ok, I posted all of the above to the web and checked into CVS.

A couple of things:

I believe I have been faithful to our process and have captured the
fundemental requirements, obvious use cases, abstract analysis classes,
etc. 

I don't feel the need to create the scenarios/sequences/etc. for each of
the type semantics identified in the SRS unless someone needs them to
clarify the requirements.

And I have a issue: 

I have looked for and consumed everything I could find on semaphore
implementation in Linux. There is nothing that I have read in the way of
the Many-to-One requirement real with assistence from the kernel. Does
somebody know something I don't? Or is it purely in the user space? I
have no problem with the latter (except for performance and bloat
concerns which I will hold until a design starts to surface) and expect
it is a brain flexing opportunity.

Anyone?

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] Semaphores - Last Draft

[Frank V. C. <fr...@co...>]

This is the last draft before I turn it into a SRS


CoreLinux++ Semaphore Requirement (1589) Draft - Version 0.4
============================================================

A Semaphore is a protocol by which processes and/or threads agree to
follow for the purpose of controlled access to a resource. The resource
can be anything that the developer considers to need access controls on,
such as memory, hardware, methods, computer instructions, and so on.

The protocol is pinned to the kernel which enforces blocking (being made
to wait) the caller until a resource is available.

Callers can elect to avoid being put into a blocked state and return
immediatley without control to the resource. Callers may also request
that they are put into a blocked state for a specified amount of time.
If, at the end of the specified time, the request has not been
satisified, it is returned with a Timeout indicator.

The owner or creator of the semaphore can elect to enforce balking
behavior on a Semaphore. When so designated, the Semaphore can turn back
any request until some condition in their solution space is met
regardless of the callers blocking options. If a caller access attempt
is balked, is it returned with a Balked indicator.

Used to serialized access to a resource (one to one)
----------------------------------------------------

When used to prevent concurrent access to a resource, the caller must
first obtain control of the associated Semaphore. When a caller has
control of the Semaphore, the resource(s) that are associated with the
Semaphore are considered locked and accessible by the caller. When the
caller has completed access of the resource it relinquishes control and
the resource is now considered unlocked. 

Attempts may be made to access the resource by other threads of
execution or from seperate processes. These callers are queued and the
requestor is put into a blocked state. In this state the caller waits
until the resource is unlocked. If multiple requests are blocking for
the same control, the determination of which caller gains access next
is, from a applications perspective, arbitrary.

When balking mode is enabled callers will be turned away as long as the
Semaphore is locked.

Used to provide concurrent finite access (one to many)
------------------------------------------------------

When used in this fashion, a Semaphore can be used as an access count
controller. The Semaphore is created, as determined by the solution
domain, with the maximum number of concurrent active callers allowed. As
long as the caller count does not reach the maximum, the arrival will be
granted immediate access. When the maximum has been reached, arriving
callers are blocked. 

When balking mode is enabled callers will be turned away until the count
reduces to less than maximum.

Used to block callers until an event occurs (many to one)
---------------------------------------------------------

When used in this fashion, a single Semaphore is used to let callers
block until some event occurs. Unlike the serialzed access, where one
caller at a time is released to gain access to a resource, when the
designated event occurs all blocked callers are released at once. 

The creator of this type of Semaphore can designate the maximum number
of listeners that can wait on a single Semaphore event. When used in
this manner, balking mode is automatically enabled.

When balking mode is enabled callers will be turned away until the
number of listeners on the event drops below maximum.

Semaphore Groups
----------------
A Semaphore group is an extension to the Linux semaphore set. This
provides a way to logically group semaphores. For example, it may be
useful in a solution domain to group One-To-One semaphores differently
from Many-to-One semaphores.

A Semaphore group acts as a semaphore factory, creating and destroying
semaphores for the user.

CoreLinux Semaphore Functional Requirements
===========================================

General Requirements
---------------------

There will be no restriction on the type of the Semaphore that can be
created other than system dependent resources.In this event, an
exception will be thrown indicating, if possible, why the Semaphore
could not be created.

The default mode for all Semaphore will be non-Balking.

All Semaphore Groups will support named creation.

All Semaphore Groups will support maximum group count creation. This
identifies the number of maximum semaphores in the group.

All Semaphore Groups will support a segregation by type (One-to-One,
One-to-Many, and Many-to-One).

All Semaphore Groups will support instrumentation.

All Semaphore "creates" will pass through a Semaphore Group.

All Semaphore "destroys" will pass through a Semaphore Group.

All Semaphores will support having a user defined identifier.

All Semaphores will maintain a group and instance identifier.

Callers will be able to "get" a Semaphore by it's Group and Instance
Identifier.

Callers will be able to "get" a Semaphore by it's Instance Identifier.

All Semaphores will support instrumentation.

All Semaphores will support access by only the process that creates it.

All Semaphores will support access by the process that creates it, and
any children that the process spawns.

All Semaphores will support access by any process.

All Semaphores will support read only operations for each of the above
access modes.

All Semaphores will support read/write operations for each of the above
access modes.

All Semaphores will support a recursion disposition.

All other Semaphores will support a lock semantic in that the caller
will wait until the lock is obtained.

All Semaphores will support the lock semantic with no-wait option so
that the caller will return immediatley if the lock can not be
immediatley obtained.

All Semaphores will support the lock semantic with timeout option so
that the caller can indicate a maximum amount of time before giving up
trying to obtain the lock.

General One-to-One Semaphore
----------------------------
One-to-One Semaphores will support a create and automatically lock
capability. 
One-to-One Semaphores will support a create and no-lock capability.

General One-to-Many Semaphore
-----------------------------
One-to-Many Semaphores will support a create with a maximum resource
count.
One-to-Many Semaphores will support a create and automatically lock
capability which means no resources are available.
One-to-Many Semaphores will support a create and no-lock capability
which means all (maximum) resources are available.
One-to-Many Semaphores will support increasing the maximum count.

General Many-to-One Semaphore
-----------------------------
Many-to-One Semaphores will support a create with a maximum "listener"
count
Many-to-One Semaphores will automatically lock upon creation. There is
not option to create it unlocked.
Many-to-One Semaphores will support increasing the maximum "listener"
count if balking mode enabled.

General Semaphore Groups
------------------------
CoreLinux++ will support a default, heterogeneous, Semaphore Group. Name
TBD, maximum semaphore count TBD.
CoreLinux++ default group shall chain new group instances for user "get"
operations.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] Am I still on track.

[Frank V. C. <fr...@co...>]

Jacob Christen wrote:
> 
> >Am I correct in assuming, by the complete silence, in regards to the
> >Semaphore requirements posting that everyone is satisfied with what is
> >emerging?
> 
> at least, in my case yes.  i like what i see.
> 
> let me make a general apology for the silence on my part--i am trying to
> assimilate whats been done and where i can fit in.
> 
> (and whether or not i like magic draw uml--i'm used to rose :P)

You and me both. MD is suppost to have a new version this week (3.51),
which addresses some issue I have posted with the tool. 
 

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] Am I still on track.

[Frank V. C. <fr...@co...>]

Joe Nelson wrote:
> 
> > Am I correct in assuming, by the complete silence, in regards to the
> > Semaphore requirements posting that everyone is satisfied with what is
> > emerging?
> 
> I think this conception of a semaphore is interesting because it also
> incorporates Events into the class. I've been wondering, though, would it
> be possible to put Event, Mutex, and Semaphore all in one class somehow?
> I think if it's done right it wouldn't be tacky at all, but elegant. It
> seems to me that all these concepts have behavior and structure in
> common. Or, even if they couldn't reasonably be put into the same class,
> I'm sure they could be put into a hierarchy to leverage polymorphism
> better.
> 
> What do you think?

Without getting into an implementation, what is common to all is
potentially factored in the design. But I am confused by your message,
do you mean one (1) class for all semaphores or, as your last sentence
mentions, a semaphore hierarchy?

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] Garbage Collection (Errata).

[Frank V. C. <fr...@co...>]

"Frank V. Castellucci" wrote:
> 
> Take a look at http://www.ukc.ac.uk/computer.science/Html/Jones/gc.html

Sorry, page is out of date, try

http://www.cs.ukc.ac.uk/people/staff/rej/gc.html


-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] Garbage Collection.

[Frank V. C. <fr...@co...>]

"Nicholas D Salerno;951;esen1;" wrote:
> 
>         Looking at the requirements, I was thinking about the garbage
> collection requirement.  Would this be in the library or the framework?

It would be in a framework module.

> I would think that it would be in the framework.  The library is there as
> a toolkit where developers pick and choose what classes they need, but do
> this at the expense of not having the garbage collection, and probably a
> few other things.  The framework, on the other hand, is something you just
> can't pick and choose from, once you use it, you pretty much get most of
> it, if not all of it, including garbage collecting.  Do this sound right

Yes.

>         As for possible design of a garbage collector, I am curious as how
> one works.  I know what Java does, but that is not what we have.  We don't
> have a middle layer that C++ programs run through.  It would be more like
> Eiffel, in which Eiffel programs have garbage collection while being
> standalone programs.  What I am thinking is that someone is responsible
> for overseeing all the references to all dynamic objects in the system.

We can be more flexible than that.

> Perhaps all assignment operations are required to check with this
> GarbageMan to see if the left side of the operation, prior to assignment,
> is going to lose its last reference, in which case the GarbageMan
> deallocates the object.  Just thinking about it I realize that this is not
> done on a periodic basis, it is happening on demand per assignment
> operatoin, which may get expensive?
> 
>         Nicholas

Take a look at http://www.ukc.ac.uk/computer.science/Html/Jones/gc.html

Or

Garbage Collection
Algorithms for Automatic Dynamic Memory Management
Richard Jones, Rafael Lins
John Wiley & Sons
ISBN 0-471-94148-4

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://www.colconsulting.com 
Object Oriented Analysis and Design |Java and C++ Development

Re: [Corelinux-public] Garbage Collection.

[Frank V. C. <fr...@co...>]

Dan Kegel wrote:
> 
> "Nicholas D Salerno;951;esen1;" wrote:
> >         Looking at the requirements, I was thinking about the garbage
> > collection requirement.  Would this be in the library or the framework?
> 
> Anything that's got a garbage collection framework shouldn't be called
> CoreLinux, IMHO, as it's certainly not core to Linux.
> 
> You might consider renaming the package after some cuddly animal...
> 
> - Dan

The only name we have for frameworks so far is libcoreframework from a
module standpoint. Garbage collection does not need to reside in this
particular framework module. I believe we stated somewhere, note
searching, that we would modularize the frameworks so that others could
substitute their own derivations or replacements.

The only garbage collection cuddly animal that comes to my mind is a
rat. Altough not having one I have cuddled...

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] Garbage Collection.

[Dan K. <da...@al...>]

"Nicholas D Salerno;951;esen1;" wrote:
>         Looking at the requirements, I was thinking about the garbage
> collection requirement.  Would this be in the library or the framework?

Anything that's got a garbage collection framework shouldn't be called
CoreLinux, IMHO, as it's certainly not core to Linux.

You might consider renaming the package after some cuddly animal...

- Dan

Re: [Corelinux-public] Am I still on track.

[Jacob C. <jac...@ho...>]

> Do mutexes come into play somewhere?  Will this be tied to
>threading (in which is it wrapping some existing thread library or are we
>creating our own)?  Looks good so far.
> I also apologize for my silence, it is approx. 1 week before all
>my final exams are done and then I can concentrate on this.
>
> Nicholas


semaphores here are not the specific os-type semaphores you may be used
to working (or are simply more familiar) with.  semaphores generalized in
the
context of corelinux are simply objects that control programatically access
to
resource(s).  in this sense, a mutex semaphore is a semaphore that you wait
on for ownership and once you own it no other thread can until you release
it.
similarly, an event semaphore (win32 event, pthread cond var) is a semaphore
you wait on to be notified of some condition.

familiar concepts with slightly different names that fit into an elegant
heirarchy.

the corelinux semaphore draft takes this a step further by removing
references
to old/familiar names (mutex, condition varaible, etc) and generalizing the
types
of control needed by various multi-threaded applications.  however, given
the
discussion frank and i had in the  Class Library and Framework Requirements
forum, some implementations of this draft could vary well end up with
objects
like Mutex and Event or ConditionVariable that meet the requirements laid
out.

jacob

[Corelinux-public] Garbage Collection.

[Nicholas D Salerno;951;esen1; <nd...@cs...>]

	Looking at the requirements, I was thinking about the garbage
collection requirement.  Would this be in the library or the framework?
I would think that it would be in the framework.  The library is there as
a toolkit where developers pick and choose what classes they need, but do
this at the expense of not having the garbage collection, and probably a
few other things.  The framework, on the other hand, is something you just
can't pick and choose from, once you use it, you pretty much get most of
it, if not all of it, including garbage collecting.  Do this sound right
to anyone?  I like the idea of having garbage collection.  Unfortunately,
everyone just about runs into memory leaks.  I would not like to have a
mechanism that allows for people to be less careful, but it would be
easier to have garbage collection as opposed to having strict standards to
try to keep every developer in check when they allocate memory and fiddle
with pointers all over the place.
	As for possible design of a garbage collector, I am curious as how
one works.  I know what Java does, but that is not what we have.  We don't
have a middle layer that C++ programs run through.  It would be more like
Eiffel, in which Eiffel programs have garbage collection while being
standalone programs.  What I am thinking is that someone is responsible
for overseeing all the references to all dynamic objects in the system.
Perhaps all assignment operations are required to check with this
GarbageMan to see if the left side of the operation, prior to assignment,
is going to lose its last reference, in which case the GarbageMan
deallocates the object.  Just thinking about it I realize that this is not
done on a periodic basis, it is happening on demand per assignment
operatoin, which may get expensive?

	Nicholas

Re: [Corelinux-public] Am I still on track.

[Nicholas D Salerno;951;esen1; <nd...@cs...>]

On Tue, 15 Feb 2000, Frank V. Castellucci wrote:

> Am I correct in assuming, by the complete silence, in regards to the
> Semaphore requirements posting that everyone is satisfied with what is
> emerging?
> 
	Do mutexes come into play somewhere?  Will this be tied to
threading (in which is it wrapping some existing thread library or are we
creating our own)?  Looks good so far.
	I also apologize for my silence, it is approx. 1 week before all
my final exams are done and then I can concentrate on this.

	Nicholas

Re: [Corelinux-public] Am I still on track.

[Jacob C. <jac...@ho...>]

>Am I correct in assuming, by the complete silence, in regards to the
>Semaphore requirements posting that everyone is satisfied with what is
>emerging?


at least, in my case yes.  i like what i see.

let me make a general apology for the silence on my part--i am trying to 
assimilate whats been done and where i can fit in.

(and whether or not i like magic draw uml--i'm used to rose :P)

Re: [Corelinux-public] Am I still on track.

[Joe N. <3ne...@pr...>]

> Am I correct in assuming, by the complete silence, in regards to the
> Semaphore requirements posting that everyone is satisfied with what is
> emerging?

I think this conception of a semaphore is interesting because it also
incorporates Events into the class. I've been wondering, though, would it
be possible to put Event, Mutex, and Semaphore all in one class somehow?
I think if it's done right it wouldn't be tacky at all, but elegant. It
seems to me that all these concepts have behavior and structure in
common. Or, even if they couldn't reasonably be put into the same class,
I'm sure they could be put into a hierarchy to leverage polymorphism
better.

What do you think?

[Corelinux-public] Am I still on track.

[Frank V. C. <fr...@co...>]

Am I correct in assuming, by the complete silence, in regards to the
Semaphore requirements posting that everyone is satisfied with what is
emerging?

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux