Type-Safe / Thread-Safe

  • Thread starter Thread starter Scott M.
  • Start date Start date
S

Scott M.

Can someone explain the two terms "type-safe" and "thread-safe"? I
understand what a type and a thread are, but what does it mean for them to
be "safe"?
 
Larry Lard said:
Note that these terms are differently applicable; type safety is a
property of languages, whereas thread safety is a property of
particular pieces of code. The wikipedia entries look OK for both:

I think that that is slightly over simplistic.
As the wiki says - type safety can be enforced at compile time or at
runtime. C# is type safe because the runtime will not permit invalid type
casting, however compile time type safety is obviously safer in than runtime
type safety and from this you can expand the definition of typesafety to
include coding. The obvious examples are the collections:

An ArrayList intended to hold ints is type-safe only in the sense that
nothing in it can be treated as an int unless it actually is one. It is not
type-safe in that there is nothing to stop someone putting a string in it.

List<int> is type-safe in a much stronger sense because it is type-safe at
compile time rather than runtime and yet this due to the particular class
rather than the language.

Similarly there are gradations of thread-safety.
A method may be thread safe whereas a way of using it is not.
The classic example is:

for(i=0; i< list.Length; ++i)
{
doStuff(list);
}

This would not normally be considered thread-safe regardless of whether or
not the Length property and the indexer are thread-safe.
 
Type-Safe refers to the language's ability to prevent you from doing
something like this:

dim s as string
dim i as integer

s = "My String"
i = s

Preferably, this protection is done at compile time and not at run time.

Thread-Safe refers to objects and methods in those objects being protected
from internal corruption when multiple execution threads simultaneously
update the object (or update while reading). These types of errors can be
extremely hard to troubleshoot.

Mike Ober.
 
So, in VB.NET, if you had Option Strict turned on (which prevents late
binding and implicit casts), would VB.NET then be considered Type-Safe?


Nick Hounsome said:
Larry Lard said:
Note that these terms are differently applicable; type safety is a
property of languages, whereas thread safety is a property of
particular pieces of code. The wikipedia entries look OK for both:

I think that that is slightly over simplistic.
As the wiki says - type safety can be enforced at compile time or at
runtime. C# is type safe because the runtime will not permit invalid type
casting, however compile time type safety is obviously safer in than
runtime type safety and from this you can expand the definition of
typesafety to include coding. The obvious examples are the collections:

An ArrayList intended to hold ints is type-safe only in the sense that
nothing in it can be treated as an int unless it actually is one. It is
not type-safe in that there is nothing to stop someone putting a string in
it.

List<int> is type-safe in a much stronger sense because it is type-safe at
compile time rather than runtime and yet this due to the particular class
rather than the language.

Similarly there are gradations of thread-safety.
A method may be thread safe whereas a way of using it is not.
The classic example is:

for(i=0; i< list.Length; ++i)
{
doStuff(list);
}

This would not normally be considered thread-safe regardless of whether or
not the Length property and the indexer are thread-safe.
 
Yes - for the most part - especially if you are using VB 2005. VB, and the
rest of .NET, contains the "Object" type which can contain any type.
However, to do anything with it, you must explicitely cast it to a different
type at runtime. In VB 2005, this is done via the CType(myOjb, <target
type>). Note that this cast can fail with an exception.

Mike.

Scott M. said:
So, in VB.NET, if you had Option Strict turned on (which prevents late
binding and implicit casts), would VB.NET then be considered Type-Safe?


Nick Hounsome said:
Larry Lard said:
Scott M. wrote:
Can someone explain the two terms "type-safe" and "thread-safe"? I
understand what a type and a thread are, but what does it mean for them
to
be "safe"?


Note that these terms are differently applicable; type safety is a
property of languages, whereas thread safety is a property of
particular pieces of code. The wikipedia entries look OK for both:

I think that that is slightly over simplistic.
As the wiki says - type safety can be enforced at compile time or at
runtime. C# is type safe because the runtime will not permit invalid type
casting, however compile time type safety is obviously safer in than
runtime type safety and from this you can expand the definition of
typesafety to include coding. The obvious examples are the collections:

An ArrayList intended to hold ints is type-safe only in the sense that
nothing in it can be treated as an int unless it actually is one. It is
not type-safe in that there is nothing to stop someone putting a string in
it.

List<int> is type-safe in a much stronger sense because it is type-safe at
compile time rather than runtime and yet this due to the particular class
rather than the language.

Similarly there are gradations of thread-safety.
A method may be thread safe whereas a way of using it is not.
The classic example is:

for(i=0; i< list.Length; ++i)
{
doStuff(list);
}

This would not normally be considered thread-safe regardless of whether or
not the Length property and the indexer are thread-safe.
 
How is that different than VB.NET 2003? In 2003, we use CType(sourceObj,
targetType) and DirectCast(Type, targetType). With Option Strict turned on,
both should flag errors at compile time.


Michael D. Ober said:
Yes - for the most part - especially if you are using VB 2005. VB, and
the
rest of .NET, contains the "Object" type which can contain any type.
However, to do anything with it, you must explicitely cast it to a
different
type at runtime. In VB 2005, this is done via the CType(myOjb, <target
type>). Note that this cast can fail with an exception.

Mike.

Scott M. said:
So, in VB.NET, if you had Option Strict turned on (which prevents late
binding and implicit casts), would VB.NET then be considered Type-Safe?


Nick Hounsome said:
Scott M. wrote:
Can someone explain the two terms "type-safe" and "thread-safe"? I
understand what a type and a thread are, but what does it mean for them
to
be "safe"?


Note that these terms are differently applicable; type safety is a
property of languages, whereas thread safety is a property of
particular pieces of code. The wikipedia entries look OK for both:


I think that that is slightly over simplistic.
As the wiki says - type safety can be enforced at compile time or at
runtime. C# is type safe because the runtime will not permit invalid type
casting, however compile time type safety is obviously safer in than
runtime type safety and from this you can expand the definition of
typesafety to include coding. The obvious examples are the collections:

An ArrayList intended to hold ints is type-safe only in the sense that
nothing in it can be treated as an int unless it actually is one. It is
not type-safe in that there is nothing to stop someone putting a string in
it.

List<int> is type-safe in a much stronger sense because it is type-safe at
compile time rather than runtime and yet this due to the particular class
rather than the language.

<http://en.wikipedia.org/wiki/Type_safety>


Similarly there are gradations of thread-safety.
A method may be thread safe whereas a way of using it is not.
The classic example is:

for(i=0; i< list.Length; ++i)
{
doStuff(list);
}

This would not normally be considered thread-safe regardless of whether or
not the Length property and the indexer are thread-safe.

<http://en.wikipedia.org/wiki/Thread_safety>


 
Back
Top