[CSDb] - User Forums - Some sort of multithreading.

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Some sort of multithreading.

2008-04-08 22:51

gregg
Account closed

Registered: Apr 2005
Posts: 56

Some sort of multithreading.

About a week ago the topic multithreading came up on #c-64. So today I gave it a try. However, there's something wrong with my code and I can't really figure out what it is.

A short description: I have a fixed number of threads running and a CIA IRQ deals with context switching in a round-robin fashion. Every IRQ I save all current state data (SP, status register, PC, A, X, Y) in a structure and fetch the state data for the next thread.

In this example the first thread increments the screen background color (fast), while the second thread changes the border background color (slow). However the wait in the second thread runs too fast every other time, and I have no idea why. It's probably something wrong with the context switch stuff, maybe some of you could take a look at it?

Sources are for ACME.

!to "threading.prg",cbm
!cpu 6510
;!source "mylib.a"
!macro basic_header .a, .b, .c, .d {
        *= $0801
        !byte <.eol,>.eol,0,0,$9e
        !text .a, .b, .c, .d
.eol:   !byte 0,0,0
}

num_threads = 2
thread_num = $fd		; current thread number

;--------------------------------------------------------------------------
+basic_header "2", "0", "6", "1"

*= $080d

init:	sei
		; set up context switch IRQ
		lda #$35
		sta $01

		lda #<context_switch
		ldx #>context_switch
		sta $fffe
		stx $ffff
		
		lda #0
		sta thread_num

		cli
		jmp thread1

;--------------------------------------------------------------------------
context_switch:
		pha
		txa
		pha
		tya
		pha
		lda $dc0d

		; save current thread
		lda thread_num
		; *8
		asl
		asl
		asl
		tay
		; save A,X,Y
		pla
		sta thread_data+6,y
		pla
		sta thread_data+5,y
		pla
		sta thread_data+4,y
		; save PSW
		pla
		sta thread_data+1,y
		; save PC
		pla
		sta thread_data+2,y
		pla
		sta thread_data+3,y
		; save SP
		tsx
		txa
		sta thread_data,y

		; next thread, wraparound
		ldy thread_num
		iny
		cpy #num_threads
		bne +
		ldy #0
+		sty thread_num

		; *8
		tya
		asl
		asl
		asl
		tay

		; restore thread data
		; stack pointer first
		lda thread_data,y
		tax
		txs
		; push PC, PSW for RTI
		lda thread_data+3,y
		pha
		lda thread_data+2,y
		pha
		lda thread_data+1,y
		pha
		; push registers
		lda thread_data+6,y
		pha
		lda thread_data+5,y
		pha
		lda thread_data+4,y
		pha

		pla
		tay
		pla
		tax
		pla
		rti
	
;--------------------------------------------------------------------------
thread1:
		inc $d021
		ldy #$02
		jsr wait2
		jmp thread1


thread2:
		inc $d020
		ldy #$80
		jsr wait2
		jmp thread2
		
wait2:
-		ldx #0
		dex
		bne *-1
		dey
		bne -
		rts

;--------------------------------------------------------------------------
thread_data:
	!fill 8, 0
	!byte $ff-$40, $22, <thread2, >thread2, 0,0,0,0

... 211 posts hidden. Click here to view all posts....

2008-04-16 22:08

Martin Piper

Registered: Nov 2007
Posts: 722

Even the link you cite proves you are wrong.

"A process may split itself into multiple 'daughter' ... threads"

It cannot be any simpler. Threads live inside processes. This is multi-tasking.

Processes can be multi-tasked.
http://en.wikipedia.org/wiki/Computer_multitasking
"multitasking is a method by which multiple ... processes ... share common processing resources such as a CPU."

This is multi-tasking.

Therefore in multi-tasking you have multiple processes which can each have multiple threads running inside each process.

It looks like this:
"OS" -> Processs -> Threads

2008-04-16 22:19

Martin Piper

Registered: Nov 2007
Posts: 722

Gregg's code is not a collection of processes, this is because processes are generally defined as independant programs that are in their own address space and interact only through OS calls. This means Gregg's code is not multi-tasking.

Gregg's code is a collection of threads (two threads to be exact) where the code is in the same address space. Because Gregg's code only has a one dimensional list of threads this means it is multi-threading.

If Gregg's code had a two dimensional array of threads, where each process could have its own block of threads, this would be multi-tasking.

This disproves what you have been posting. Especially since your own links disprove what you have been posting.

2008-04-16 22:37

Martin Piper

Registered: Nov 2007
Posts: 722

This quote from you explains exactly why you get it completely wrong:
"gregg havent implemented processes, thus he cant have threads either."

This is because the quote you cited from one link disproves your statement:
"Multithreading is running multiple lightweight threads of execution in a single process / task / program."

Note it says "single process/task/program". This means it is not mandatory to have support for multiple processes to be able to have support for threads. Threads can happily exist in one program or bit of code. This means no hierarchy. Gregg's code is one program. This is called multi-threading.

2008-04-16 23:02

Oswald

Registered: Apr 2002
Posts: 5094

"Multi-threading = Gregg's code because it does not support multiple processes that can have threads threads. No hierarchy."

no hierarchy = multitasking without multithreading
hierarchy = multitasking with multithreading

there's NO multithreading WITHOUT multitasking.

threads are defined as something thats inside processes, and there are no processes without multitasking:

In computing, a process is an instance of a computer program that is being sequentially executed[1] by a computer system that has the ability to run several computer programs concurrently.

"Multi-tasking = Multiple processes that can support multiple threads. A hierarchy."

nope. multitasking may be or may not be multithreading. multitasking doesnt support multithreading by definition. see Amiga OS for example. it is a preemptive multitasking OS without threads.

"that means it is doing multi-threading because it has one process with multiple threads inside that one process."

process cannot be defined as a process in a non multitasking but multithreading system. see above. processes are part of multitasking systems.

"Again this is from your own post:
"Multi-threading is running multiple lightweight threads of execution in a single program.""

...which program runs in a multitasking enviroment. as threads are inside processes and processes are inside multitasking OS-es. see the definitions I have quoted.

"Therefore in multi-tasking you have multiple processes which can each have multiple threads running inside each
process."

WRONG. see Amiga OS and similar again. first there was multitasking without threads. and only later were threads invented.

"It looks like this:
"OS" -> Processs -> Threads"

AmigaOS == multitasking: OS -> Process. end of story.

"Gregg's code is not a collection of processes, this is because processes are generally defined as independant programs that are in their own address space and interact only through OS calls. This means Gregg's code is not multi-tasking."

then its neither multitasking nor multithreading. I can live with that.

"Gregg's code is not a collection of processes"

fine. that means it cant have threads either. as threads are inside processes. no process - no threads.

"Gregg's code is a collection of threads (two threads to be exact) where the code is in the same address space."

cant be threads either. threads have their own stack. gregg's threads are sharing the same stack.

"If Gregg's code had a two dimensional array of threads, where each process could have its own block of threads, this would be multi-tasking"

Amiga OS.

"This disproves what you have been posting. Especially since your own links disprove what you have been posting."

not at all. only shows your lack of knowledge. multithreading is not a must for multitasking. see Amiga OS.

2008-04-16 23:20

Oswald

Registered: Apr 2002
Posts: 5094

Quote: This quote from you explains exactly why you get it completely wrong:
"gregg havent implemented processes, thus he cant have threads either."

This is because the quote you cited from one link disproves your statement:
"Multithreading is running multiple lightweight threads of execution in a single process / task / program."

Note it says "single process/task/program". This means it is not mandatory to have support for multiple processes to be able to have support for threads. Threads can happily exist in one program or bit of code. This means no hierarchy. Gregg's code is one program. This is called multi-threading.

"In computing, a process is an instance of a computer program that is being sequentially executed[1] by a computer system that has the ability to run several computer programs concurrently."

no support for multiple processes = no processes. no processes = no threads.

btw,

"It looks like this:
"OS" -> Processs -> Threads"

and in your dream it looks like this: -> threads. are you really so sure that does make any sense?

you either have OS -> Process -> Threads
or OS -> process (amiga)
or OS (c64)

but this is just silly : -> threads.

2008-04-17 08:35

Skate

Registered: Jul 2003
Posts: 494

actually multi-threading can exist without multi-tasking. but there is no OS exists using multi-threading and not multi-tasking. this is why Oswald is confused. he still thinks that 9th sprite cannot be shown in a raster line ;)

gregg's code definitely is not a multi-tasking example. to have multi-tasking you need to take care of a lot more things. specially about hardware specific features. for example if two of your applications (processes) are using sprites, you need to switch all sprite specific addresses ($d000-$d02f, SCREEN_MEMORY+$3f8-SCREEN_MEMORY+$3ff etc.) automaticly each time you switch between processes. "different processes must not affect each other!!!" this is why these documents say "multi-tasking is OS based". actually you don't need an OS for multi-tasking. But when you write these kind of process switch handling routines, it means that you've deleloped a very big structure of an OS.

I hope you have a more clear view about this now.

2008-04-17 09:38

Martin Piper

Registered: Nov 2007
Posts: 722

Quote: actually multi-threading can exist without multi-tasking. but there is no OS exists using multi-threading and not multi-tasking. this is why Oswald is confused. he still thinks that 9th sprite cannot be shown in a raster line ;)

gregg's code definitely is not a multi-tasking example. to have multi-tasking you need to take care of a lot more things. specially about hardware specific features. for example if two of your applications (processes) are using sprites, you need to switch all sprite specific addresses ($d000-$d02f, SCREEN_MEMORY+$3f8-SCREEN_MEMORY+$3ff etc.) automaticly each time you switch between processes. "different processes must not affect each other!!!" this is why these documents say "multi-tasking is OS based". actually you don't need an OS for multi-tasking. But when you write these kind of process switch handling routines, it means that you've deleloped a very big structure of an OS.

I hope you have a more clear view about this now.

Yes, that is exactly the reason why Oswald is confused.

2008-04-17 09:42

Martin Piper

Registered: Nov 2007
Posts: 722

Oswald your examples of Amiga OS are wrong because each process can have threads inside it, if the code is written to support it. Another example would be my pthread library for RISC OS which allowed pre-emptive multithreading inside each task where each task has its own memory mapped space from the MMU. The point being that the support for each process in the OS is heavyweight enough to allow each process to have its own threads, either from the OS or by using its own interrupts, if needed. This heavyweight handling of each process, as the poster above says, involves switching in and out lots of context information, not just threading information but also interrupts, graphics, sound, input devices etc. This is the hierarchy which I have been writing about. The hierarchy doesn't just mean thread information, although since this topic is dealing with threading specifically then threading is a good example of part of this hierarchy, it means everything related to the computer that needs to be saved and restored with each process switch.

Oswald, in post 144 you quoted:
"Multitasking is running multiple "heavyweight" processes (tasks) by a single OS."

And:
"Multithreading is running multiple "lightweight" processes (threads of execution) in a single process / task / program. See What is the difference between a lightweight and a heavyweight process:"

Do you agree that the terms lightweight refers to multi-threading and that heavyweight refers to multi-tasking?

2008-04-17 13:51

Oswald

Registered: Apr 2002
Posts: 5094

Skate,

you seem to be have only blurry ideas even about some of the most basic OS concepts. You are mixing up the concepts "adress space" and "resource management".

resources(sprites):

"A resource, or system resource, is any physical or virtual component of limited availability within a computer system."

adress space:

"In general, things in one address space are physically in a different location than things in another address space. For example, "house number 101 South" on one particular southward street is completely different from any house number (not just the 101st house) on a different southward street."

you write:

"different processes must not affect each other!!!"

well, your own example doesnt fullfills that requirement. as the process in your example can write each others memory happily, except sprite registers. but sprite registers should be handled through resource allocation / sprite drivers, and not with different adress spaces. different adress spaces are there to avoid the process messing up each others memory. as a thumb of rule no process should be able to change any low level I/O regs directly, only through OS provided routines.

I hope you have a more clear view about this now.

the rest of your statements are not arguable, as you provided no proofs to support them.

Previous - 1 | ... | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 - Next

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

E$G/HF ⭐ 7
iceout/Avatar/HF
fuzzybad
t0m3000/hf^boom!^ibx
Paladin/G★P
Guests online: 145

Top Demos

1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)

Top onefile Demos

1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 X-Mas Demo 2024  (9.5)
7 Dawnfall V1.1  (9.5)
8 Rainbow Connection  (9.5)
9 Onscreen 5k  (9.5)
10 Morph  (9.5)

Top Groups

1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)

Top Fullscreen Graphicians

1 Joe  (9.7)
2 Sulevi  (9.6)
3 The Sarge  (9.6)
4 Veto  (9.6)
5 Facet  (9.6)

Page generated in: 0.056 sec.