1. 아니 PCB는 Process의 상태를 저장하고 복원하는데 쓰이는 자료구조인데, 만약에 같은 Process에 존재하는 Thread간에 Context Switching이 발생하는 경우에는 어떻게 상태를 추적할 것인가?
   
2. 실행되는 작업의 최소 단위는 Process가 아니라 Thread라는 것을 보면 Context Switching의 실질적인 기준이 되는 것도 Thread 여야 되는 것 아닌가?
   
3. 근데 PCB가 이러한 것들을 다 감당하는 자료구조인가?

그래서 검색해본 결과 TCB라는 새로운 자료구조를 알게되었음

TCB - Thread Control Block

Thread의 상태를 저장하는 자료구조 다음과 같이 PCB에 연결된 리스트에 존재함

Thread Context Switching이 발생하면

Thread A가 CPU 사용중 Thread A의 상태 정보를 TCB A에 저장 Thread A가 속한 Process A의 상태 정보 PCB A에 저장 Thread B가 속한 Process B의 상태 정보 PCB B 로드 Thread B의 TCB B 로드 Thread B가 CPU 사용

과 같은 과정이 실행된다고 한다 그리고 gpt한테 물어봤는데 Context Switching의 실질적인 기준이 되는것도 Thread가 맞다 함 아 근데 먼가 확실ㄹ하지 않고 애매한거 같아서 더 찾아보고 공부해바야 될듯

방문 상태를 저장 할 경우 배열로 선언하는 것보다 비트마스킹 형태의 정수로 저장하면 공간복잡도 측면에서 효율적으로 코드 작성 가능

• 추가 파이썬에서 딕셔너리의 특정 키 존재 유무 파악할 때 그냥 in 연산자 적어주면 된다. 시간복잡도 o(1)

비트스트림에서 i번째 인덱스의 값을 딕셔너리의 키가 i일때 value 값을 구하는 방식으로 구현

훨씬 직관적인듯

mtbf = 고장률의 역수

• 고장률 = 고장건수 / 총가동시간

mttf = 총가동시간 / 고장시간

mttr = 총고장시간 / 고장건수

가용도 = mttf / mtbf

cpm 네트워크

타당성 3가지

기술적 타당성 = 프로젝트가 기술적으로 가능한지 경제적 타당성 = 프로젝트가 경제적으로 가능한지 (이익을 창출할 수 있을지) 운영적 타당성 = 프로젝트가 실제로 사용 가능한지 (조직과 잘 맞음? 클라이언트가 사용 가능?)

유스케이스 다이어그램

통신 다이어그램

• 직사각형 : 객체
• 선 : 관계
• 화살표 : 메세지가 흐르는 방향
• 번호 : 메세지 전송 순서

순차 다이어그램

비용 산정 기법

• 상향식
  • loc = 라인 / (생산성 * 프로그래머)
  • cocomo
    • 조직형 = 조직형 (소규모 소프트웨어, 비즈니스 로직)
    • 반분리형 = 30만 라인 이하
    • 내장형 = 30만 라인 이상 (운영체제, 대규모 트랜잭션)

    ---

    • 기본형 = 라인 수와 개발 유형 사용해서 비용 산정
    • 중간형 = 제품, 컴퓨터, 개발자 특성 고려해 비용 산정
    • 발전형 = 개발 공정별로 더욱 자세하게 비용 산정

    ---

    • 보정 후 기능 점수 = 기본 점수 * 보정 인자
• 하향식 (전문가들)

dfd

• data store = db테이블
• terminator = 대상
• process = 수행
• data flow = 데이터 이동

bisect 라이브러리 추가 공부 ㄱ

https://school.programmers.co.kr/learn/courses/30/lessons/258709

이벤트 루프

자바 스크립트 코드 실행은 스레드에서 담당하고 비동기작업은 이벤트 루프에 등록되어 백그라운드엣에서 실행됨 이벤트 루프는 요청을 처리하면서 블로킹 작업을 피하고 (non-blocking), 작업이 완료될 때까지 기다리는 대신 다른 작업을 계속 진행할 수 있게 함. 콜 스택 과 태스크 큐를 사용

콜 스택 (call stack)

자바스크립트 코드가 실행되는 공간. 코드가 동기적이면 콜 스택에서 순차적으로 처리됨

태스크 큐 (task queue)

비동기 작업(예: 네트워크 요청, 파일 읽기, 데이터베이스 접근 등)은 콜 스택에서 바로 처리되지 않고 백그라운드에서 실행. 백그라운드에서 실행된 작업이 완료되면 그 결과가 태스크 큐에 담김 *태스크 큐에 쌓인 작업은 콜 스택이 비어 있을 때 이벤트 루프가 이를 콜 스택으로 다시 가져와 실행함 *

소켓 통신은 서로 다른 컴퓨터에 있는 프로세스 사이에 데이터를 주고 받기위해 사용되는 기술이다. 소켓 통신은 클라이언트와 서버가 실시간으로 데이터를 주고 받을 수 있는 양방향 통신으로 채팅, 실시간 스트리밍 등에 사용된다. 소켓 통신은 IP와 포트번호를 통해 어떤 컴퓨터의 어떤 프로세스와 통신할지 구별한다

근데 갑자기 다음과 같은 궁금증이 생겨버림

아니 근데 내가 알기로는 HTTP 통신도 서버랑 클라이언트가 실시간으로 데이터 주고 받는 기술이고, HTTP 통신도 IP와 포트번호를 통해 어떤 컴퓨터의 어떤 프로세스와 통신할지 구별하는데, 둘이 같은거 아님?

그래서 찾아보니까 HTTP 통신은 소켓 통신이 맞음. TCP 계층에 올라간 HTTP 또한 소켓 통신과 같은 방식을 사용함. 즉 HTTP 통신은 소켓 통신에 일종이라고 볼 수 있으나, 소켓 통신은 HTTP 통신이 아님

추가

• HTTP 통신은 클라이언트의 요청이 들어왔을 때 서버가 응답하는 단방향 통신, 서버는 응답하면 클라이언트와 커넥션을 끊어버림. 즉 *실시간 통신이 아님 * -> 그러나 현재는 Keep Alive 옵션을 통해 커넥션 유지 가능 즉 근본자체는 실시간 통신이 아니기 때문에 내가 기존에 알고있던 내용은 틀린 내용
• 초기에는 HTML 파일만 전송하였으나, 현재는 JSON, 이미지 파일 등도 전송 가능

아 퇴사하고 오랜만에 공부하니까 개재밌네 ㅎ

접근

사각형을 하나씩 순회하면서 모서리 부분은 1, 안쪽 부분이거나 다른 사각형의 안쪽부분이라면 0으로 그래프 초기화

코드

from collections import deque


def solution(rectangle, characterX, characterY, itemX, itemY):

    leng=max(list(map(max, rectangle)))*2
    graph=[[5 for i in range(leng+1)] for j in range(leng+1)]
    visited=[[0 for i in range(leng+1)] for j in range(leng+1)]
    answer=10000
    movelist=[[1,0],[-1,0],[0,-1],[0,1]]
    for re in rectangle:
        re=list(map(lambda x:x*2,re))
        for i in range(re[1],re[3]+1):
            for j in range(re[0],re[2]+1):
                if graph[i][j]!=0 and (i==re[1] or i==re[3] or j==re[0] or j==re[2]):
                    graph[i][j]=1
                else:
                    graph[i][j]=0

    curx,cury=characterX*2, characterY*2
    visited[cury][curx]=1
    itemx,itemy=itemX*2, itemY*2
    queue=deque()
    queue.append([curx,cury,0])

    while queue:
        curx,cury,curd=queue.popleft()
        if curx==itemx and cury==itemy:
            answer=min(answer,curd//2)

        for mo in movelist:
            nx,ny=curx+mo[0],cury+mo[1]
            if 0<=nx<leng+1 and 0<=ny<leng+1 and visited[ny][nx]==0 and graph[ny][nx]==1:
                queue.append([nx,ny,curd+1])
                visited[ny][nx]=1

    return answer

참고

실제 문제의 좌표평면을 그래프상의 숫자 0과1로 옮길떄 주의해야 할 점은 다음과 같다

좌표평면의 ㄷ자 모양과 ㅁ자 모양을 그래프로 옮길 경우 두 그래프의 형태 모두 1 1 1 1 로 표현된다. 그렇기 떄문에 위와같은 문제를 해결할 떄는 그래프의 좌표를 2배로 늘려주는 방식 또한 고려해야한다. 만약 위 경우를 그래프를 두배로 늘렸을 경우로 표현한다면

1 1 1 0 0 1 0 0 0 과 1 1 1 1 1 1 1 1 1로 정상적으로 구별이 가능해진다.

Security Config

Success handler 추가

Session Management

• 최대 로그인 세션 1개로 제한 -> 중복 로그인 제한

  formLogin

• defaultsuccessurl 방식에서 successHandler 방식으로 변경, 이게 인증,인가 다룰때 더 좋은듯

  oauth login 속성 추가

• 사실 이번 리팩토링의 가장 큰 이유인 부분. 구글 로그인 연동 기능 추가 , ->DB에도 정상적으로 연동된것 확인

  logout handler 추가

Controller

Main

• 메인 컨트롤러에서 authenticated 또는 authorized된사용자 정보 1차적으로 불러오게끔 변경

Member

• authenticated 유무에 따라서 redirect 되는 결과 변경

route

• 이번 리팩토링의 핵심 2, 이제 매 실행마다 이전 데이터 clear하고 실행되기 때문에 연속된 서비스 실행 가능

DTO

• 이건 별거 없음 그냥 oauth 종속성 추가함에 따라 기존 DTO에 column 추가하고 oauth속성이랑 세션멤버 dto 생성한거?

Entity

• 이것도 마찬가지

Service

• 이거 진짜 개 큰일날뻔 한게 전체 프로젝트의 가장 중요한 부분 담당하는 service 두개가 bean으로 등록이 안되어있었음... 바로 어노테이션 추가함...지금까지 어떻게 정상적으로 실행되었는지는 잘 모르겠으나 되게 기특하다ㅠ

추가

이번에는 감사하게도 로컬상에서 커밋한 내용 그대로 배포단에서 정상적으로 실행이 됐다.. 잠깐 구글oauth 측에서 redirect uri mismatch 에러가 나긴 했는데 이것도 리디렉션 uri 조금 조물조물 거리니까 되었음. 아마 자바스크립트 원본에 ec2주소 안넣고 배포 주소 넣어서 그런듯?

프론트는 변경한거 작성안함

접근

기둥배열과 보 배열을 각 각 따로 이차원 배열로 생성해주었고. 기둥과 보의 시작점과 끝점을 각각 1로 설정해준후 구현하였음.

1차 수정

0ㅡ0ㅡ0 보가 이렇게 지어져있을 때나, 0ㅡxㅡ0 이렇게 지어져있을 때나 이차원 배열의 값은 같기 떄문에 구별이 안된다. 그리하여 시작점만 1로 설정해주는 식으로 변경하였다

처음 코드

def solution(n, build_frame):
    # 기둥은 바닥위에 있거나 보의 한 쪽 끝 부분 위에 있거나 다른 기둥위
    # 보는 한쪽 끝이 기둥 위 or 양쪽 끝부분이 다른 보
    gi=[[0 for i in range(n+1)] for j in range(n+1)]
    bo=[[0 for i in range(n+1)] for j in range(n+1)]

    for bu in build_frame:
        x,y,a,b=bu
        # x y는 교차점 좌표고 교차점 기준으로 보는 오른쪽 기둥은 위쪽
        if a==0:
            # 기둥
            if b==0:
                flag=True
                # first 위에 기둥
                if gi[y+1][x]==1:
                    if not (bo[y+1][x]==1 or bo[y+1][x-1]==1):
                        flag=False

                # second 오른쪽에 보
                if bo[y+1][x]==1:
                    if not(gi[y][x+1]==1 or (bo[y+1][x-1]==1 and bo[y+1][x+1]==1)):
                        flag=False

                # third 왼쪽에 보
                if bo[y+1][x-1]==1:
                    if not(gi[y][x]==1 or (bo[y+1][x-2]==1 and bo[y+1][x]==1)):
                        flag=False

                if flag:
                    gi[y][x]=0

            else:
                # 설치
                if y==0 or gi[y-1][x]==1 or bo[y][x]==1 or bo[y][x-1]==1:
                    # 바닥이거나 기둥위거나 보 위에
                    gi[y][x]=1
        else:
            if b==0:
                flag=True
                # 삭제
                # first 왼쪽에 기둥
                if gi[y][x]==1:
                    if not(bo[y][x]==1 or bo[y][x-1]==1 or y==0):
                        flag=False

                # second 오른쪽에 기둥
                if gi[y][x+1]==1:
                    if not(bo[y][x+1]==1 or bo[y][x]==1 or y==0):
                        flag=False

                # third 오른쪽에 보
                if bo[y][x+1]==1:
                    if not(gi[y-1][x+1]==1 or gi[y-1][x+2]==1):
                        flag=False

                # fourth 왼쪽에 보
                if bo[y][x-1]==1:
                    if not(gi[y-1][x-1]==1 or gi[y-1][x]==1):
                        flag=False
                if flag:
                    bo[y][x]=0
            else:
                if (bo[y][x+1]==1 and bo[y][x-1]==1) or gi[y-1][x+1]==1 or gi[y-1][x]==1:
                    # 다른 기둥의 한 쪽 위거나 양쪽이 보
                    bo[y][x]=1



    answer = []

    for i in  range(n+1):
        for j in range(n+1):
            if gi[i][j]==1:
                answer.append([j,i,0])
            if bo[i][j]==1:
                answer.append([j,i,1])
    answer.sort()
    return answer

예제는 모두 통과하였으나 실 테스트 케이스는 반타작

2차 수정

초기코드에는 기둥 혹은 보를 삭제해줄때 해당 보 혹은 기둥많이 영향을 끼치는 부분만 고려하여 코드를 구현하였으나, 이부분에서 문제가 있었다.

인접 보와 기둥은 유지가 가능하더라도, 연쇄적으로 확장해봤을때 조건에 부합하지 않는 보와 기둥이 생길 수 도 있기때문에, 삭제 연산이 들어올 때마다 전체 기둥과 보의 적합성을 판단해야함

수정된 코드

def delete(i,j,gb,gi,bo,n):
    if gb==0:
        # 기둥
        gi[i][j]=0
    else:
        # 보
        bo[i][j]=0
    count=0
    for y in range(n+1):
        for x in range(n+1):
            if gi[y][x]==1:
                if not(y==0 or gi[y-1][x]==1 or bo[y][x]==1 or bo[y][x-1]==1):
                    return False
            if bo[y][x]==1:
                if not((bo[y][x+1]==1 and bo[y][x-1]==1) or gi[y-1][x+1]==1 or gi[y-1][x]==1):
                    return False


    return True



def solution(n, build_frame):
    # 기둥은 바닥위에 있거나 보의 한 쪽 끝 부분 위에 있거나 다른 기둥위
    # 보는 한쪽 끝이 기둥 위 or 양쪽 끝부분이 다른 보
    gi=[[0 for i in range(n+1)] for j in range(n+1)]
    bo=[[0 for i in range(n+1)] for j in range(n+1)]

    for bu in build_frame:
        x,y,a,b=bu
        # x y는 교차점 좌표고 교차점 기준으로 보는 오른쪽 기둥은 위쪽
        if a==0:
            # 기둥
            if b==0:
                # 기둥 삭제
                if not delete(y,x,a,gi,bo,n):
                    gi[y][x]=1

            else:
                # 설치
                if y==0 or gi[y-1][x]==1 or bo[y][x]==1 or bo[y][x-1]==1:
                    # 바닥이거나 기둥위거나 보 위에
                    gi[y][x]=1
        else:
            if b==0:
                if not delete(y,x,a,gi,bo,n):
                    bo[y][x]=1
            else:
                if (bo[y][x+1]==1 and bo[y][x-1]==1) or gi[y-1][x+1]==1 or gi[y-1][x]==1:
                    # 다른 기둥의 한 쪽 위거나 양쪽이 보
                    bo[y][x]=1



    answer = []

    for i in  range(n+1):
        for j in range(n+1):
            if gi[i][j]==1:
                answer.append([j,i,0])
            if bo[i][j]==1:
                answer.append([j,i,1])
    answer.sort()
    return answer

참고

사고 확장하기 데이터 그래프로 표현할때는 정확하게 되었는지 확인

이것들 왜씀?

http는 기본적으로 통신이 완료되면 클라이언트와 관계를 냅다 끊어버림. 즉 데이터가 유지되지 않는다. 그래서 웹에서 뭐 작성하다 새로고침하면 다 날라가는거임ㅋㅋ.

그러나, 어떤 데이터들은 유지되어야 할 필요가 있다.

예를들어, 우리가 특정 사이트에 로그인을 했는데, 새로고침 한번 했다고 로그아웃이 된다면 굉장히 어처구니가 없을것

그래서 이러한 데이터들을 브라우저등에 "임시로 저장" 하기 위해 사용되는 것이 바로 쿠키/세션/캐시/토큰이라고 할 수 있다~

쿠키

쿠키는 웹사이트 접속시 내 컴퓨터 혹은 웹 브라우저에 저장되는 작은 텍스트 조각이다. (크롬일 경우 브라우저에, IE일 경우 내컴퓨터에 저장됨)

쿠키에는 서버에서 유저를 식별할 수 있는 데이터들이 저장되며, 지정된 만료일이 지나면 삭제된다.

쿠키는 사용자가 수정및 삭제할 수 있고, 제 3자가 조회할 수 있기 때문에 가벼운 정보들이 저장되며 보안상 민감한 정보는 저장되지 않는다. 예를 들어 검색내역, 장바구니 내역등은 제3자에게 보여져도 보안상 큰 타격이 없지만, 사용자의 개인정보 내용등은 타인에게 보여지면 안된다.

캐시

캐시란 자주 사용하는 데이터나 값을 미리 복사해놓는 임시 장소

• (캐시는 인터넷 환경 뿐만 아니라 다양한 곳에서 사용되는 개념. 컴퓨터 하드웨어 안에서도 정보를 더 빨리 가져오기 위한 cpu캐시등이 있음)

데이터를 서버에 요청하는 과정에는 시간 및 자원이 소모된다. 그러므로 반복적으로 쓰이는 데이터는 매번 서버에 요청하는 것 보다 저장해놨다가 쓰는 것이 효율적. 이때 쓰이는 것이 캐시. 예를 들어 프로필 사진같은 경우는 짧은 시간 단위로 변화하지 않기 때문에, (여기서 짧은 시간은 밀리초 혹은 초 단위) 매번 서버에 요청하는 것 보다는 캐시에서 가져오는 것이 더 효율적임. 그래서 가끔 프로필 사진 바꿔도 새로고침 광클해야 변하는 경우 있는데 그게 프로필 사진이 캐싱돼서 그런거임 ㅇㅇ

세션

세션은 서버가 유저를 구분하기 위해 사용되는 방법이다.

우리가 특정 사이트에 접속하여 글을 쓰기 위해 로그인을 하였다고 가정하자. 그러나 기본적으로 사이트는 로그인을 하기 이전의 사용자와 로그인을 한 이후의 사용자가 동일 인물이라는 것을 알지 못한다.

그렇기 때문에 새로은 글을 작성할 때마다 로그인을 해야한다. 하지만 실제로 우리가 사이트를 이용할때 그런 번거로운 과정을 다 거치지 않는다. 그이유가 바로 "세션"때문이다.

유저가 로그인에 성공하면 서버는 세션 아이디를 사용자에게 전달하고, 사용자는 세션아이디를 쿠키에 저장한다.(그래서 크롬 종료해도 로그인 유지되는거) 서버가 유저로부터 요청을 받을 때 마다 이 세션아이디를 통해 누구의 계정인지 확인하고 요청을 수행함. (영화관에서 티켓내면 보관용만 찢어서 다시 주는거처럼)

토큰

이건 나중에 JWT하면서 ㄱ

참고

https://hongong.hanbit.co.kr/ https://devbirdfeet.tistory.com/203

접근

각각의 데이터의 크기가 크지 않아 완전탐색 알고리즘으로 접근하였다. n짜리의 원형의 외벽을 크기 2n짜리 배열을 생성하고, range(0,n)까의 반복문을 돌면서 i~i+n부분을 파싱하고 dist배열을 permutaations 한 값을 하나씩 순회하면서 최소갯수를 갱신해주었으나 몇몇 테스트 케이스에서 시간초과가 발생하였다.

수정

외벽이 원형의 형태로 주어졌기 때문에 이를 두배로 늘려 배열 형태로 변환하는 것은 맞다. 그러나 기준이 잘못되었음.

굳이 크기가 2n짜리인 배열을 선언하는 것이 아니라, weak의 크기 *2 만큼만 선언하여도 충분하다. 어차피 중요한것은 weak의 위치 보다는, 각 weak사이의 거리가 더 중요하기 때문에,

    for we in weak:
        newweak.append(we)
        newweak.append(we+n)
    newweak.sort()

전체 코드

from itertools import permutations
from collections import deque
def solution(n, weak, dist):
    minlength=100000
    newweak=[]
    check=len(weak)
    for we in weak:
        newweak.append(we)
        newweak.append(we+n)
    newweak.sort()
    dist_permu=list(permutations(dist,len(dist)))

    for i in range(check):
        for dist in dist_permu:
            cur_newweak=deque(newweak[i:i+check])
            dist=deque(dist)
            count=1
            curweak=cur_newweak.popleft()
            curdist=dist.popleft()
            flag=False
            while len(cur_newweak)>0:
                if cur_newweak[0]-curweak<=curdist:
                    cur_newweak.popleft()
                else:
                    curweak=cur_newweak.popleft()
                    if dist:
                        curdist=dist.popleft()
                        count+=1
                    else:
                        flag=True
                        break
            if flag:
                continue
            else:
                minlength=min(minlength,count)
    if minlength==100000:
        return -1
    return minlength

참고

원형은 배열로 변환, 데이터 적으면 완탐 먼저 생각

접근

동적계획법을 활용한 bootom-up 방식으로, 값이 올라갈수록 해당 경우의 수를 갱신하여 계산하고자 함

시행착오 - 금액을 기준으로 접근

처음에는 dp[n] 배열을 선언하고, 다음과 같이 money배열을 순회하면서 해당 배열의 인덱스값을 갱신해주는 방법을 선택하였다

for m in money:

    dp[i]+=dp[i-m]
    # 왜냐하면 동전이 1,2,5원이 있다고 가정할때, 
    #10원을 내는 경우의 수는 5원을 만드는 경우의 수에 5원짜리를 낸것+ 
    #8원짜리 경우의 수에 2원짜리 낸것 + 
    #9원짜리 경우의 수에 1원짜리 낸 것과 같기 때문
    #근데 이 생각은 굉장히 안일한 생각이었다.

하지만 위 로직은 잘못 되었는데, 왜냐하면 각각의 경우마다 중복된 경우를 제거하지 않았기 때문이다. 예를들어 1원 2원을 활용하여 4원을 만든다고 할때, 해당 로직은 dp[3]+dp[2]로 계산된다. 하지만 각각의 경우를 살펴보면

3을 만드는 경우의 수

1,1,1 +1 1,2 +1 2,1 +1

2를 만드는 경우의 수

1,1 +2 2 +2

위 경우처럼 중복이 발생한다. 즉 이 방법은 폐기되어야 함

해결 - 동전 갯수를 기준으로 접근

중복인 경우를 배제하면서, 이전 결과에서 현재 결과를 도출하는 식을 찾아야한다

먼저 1원 동전만을 사용해서 1원~n원을 거슬러주는 경우의수는 모두 1이다 1 1,1 1,1,1 1,1,1,1....

여기서 2원 동전을 포함하여 거스름돈을 주는 경우의수는 다음과 같다 1원 : 1 2원 : 1+1, 2 3원 : 1+2, 1+1+1 4원 : 1+1+1+1, 2+1+1, 2+2 5원 : 1+1+1+1+1, 2+1+1+1, 2+2+1

즉 n원을 1원과 2원으로 거슬러주는 경우의 수는, n을 1원만으로 거슬러주는 경우의 수 + n-2원을 1원만으로 거슬러주는 경우의 수 + n-4를 1원만으로 거슬러주는 경우의 수.... 등으로 표현할 수 있다

여기에 5가 추가된다면 이와 비슷하게 n원을 1원과 2원만으로 거슬러주는 걍우의 수+ n-5원을 1원과 2원만으로 거슬러주는 경우의 수, ..으로 표현할 수 있다.

이를 코드로 옮기면 다음과 같아짐

전체 코드

def solution(n, money):
    dp=[0]*(n+1)
    for mo in money:
        for i in range(1,n+1):
            if i==mo: # money에 포함되는건 일단 1을 더해주어야함
                dp[i]+=1
            elif i>mo:
                dp[i]+=dp[i-mo]
            dp[i]=dp[i]%1000000007

    return dp[-1]

참고

구글 각종 글

쓰레드란

• 실질적인 실행의 기본 단위
  • Linux, Windows등 대부분의 커널에서 실행의 실질적인 단위는 프로세스가 아니라 스레드임!!

• 스케쥴링의 단위

• 쓰레드들은 각자 자신의 stack 영역을 보유함(최소한 자신의 레지스터 상태를 보유함)

• 쓰레드는 프로세스 내에서 heap, data, code 영역을 공유

  쓰레드는 해당 프로세스 안의 메모리를 공유해서 사용할 수 있다. 일반적으로 프로세스는 최소한 하나의 쓰레드를 가지고 있다. 둘 이상의 스레드를 가지고 있다면 이는 멀티스레드라고함.

쓰레드의 이점

• Responsiveness(응답성) : 프로세스의 일부가 차단되었음에도 나머지 스레드는 계속해서 실행될 수 있음. ex) UI같이 응답성이 중요한 부분에서 사용자와의 상호작용을 계속해서 유지하여야 하기 때문

• Resource Sharing(자원 공유) : 쓰레드는 하나의 프로세스 내에서 실행되므로 프로세스의 자원을 공유 할 수 있고 이는 공유 메모리나 메세지패싱보다 효과적이다.

• Economy(경제성) : 쓰레드를 생성하는 것이 프로세스를 생성하는 것보다 더 적은 자원을 소비하며, 쓰레드 전환은 프로세스간 전환보다 오버헤드가 낮다. 이로인해 스레드를 경량 프로세스라고 부르기도 함.

• Scalability(확장성) : 멀티프로세서 아키텍처에서 여러 스레드가 동시에 실행될 수 있으므로 프로세스는 다중 프로세서 환경에서 성능을 향상시킬 수 있다.

  멀티프로세스 vs 멀티스레드

  

• 멀티 프로세스 : 하나의 응용프로그램을 여러개의 프로세스로 구성하여 각 프로세스가 작업을 처리하도록 하는것.

• 멀티 스레드 : 하나의 프로세스를 다수의 실행 단위로 구분하여 자원을 공유하고 자원의 생성과 관리의 중복성을 최소화하여 수행 능력을 향상시키는 것. 이 경우 각각의 스레드는 독립적인 작업을 수행해야 하기 때문에 각자의 스택과 PC 레지스터 값을 갖고 있다.

예시

• Google Docs가 프로세스고, 문서에 참여하는 사용자들을 스레드라 가정
• 만약 멀티 프로세스라면 사용자 한 명당 하나의 Google Docs
• 만약 멀티 스레드라면 여러 사람들이 각자의 임무를 하나의 Google Docs에서 동시에 마무리

• 사용자 수만큼의 Google Docs -> 1개의 Google Docs
• -> 사용 자원 감소
• 작업 후 여러개의 Google Docs 취합 -> 함께 임무 수행 (취합필요x)
• -> 통신 비용 감소

멀티스레딩의 장점

• 메모리 공간과 시스템 자원의 절약 (당연함)

• 스레드간 통신을 할 때에도 별도의 자원을 이용하는 것이 아니라 프로세스의 전역변수나 동적으로 할당된 공간인 Heap영역을 사용하면 됨(프로세스간 통신인 IPC에 비해 간단)

• 또한 스레드의 문맥교환은 프로세스의 문맥교환과 달리 캐시메모리를 비울 필요가 없어 더 빠름

  멀티스레딩의 문제점

• 공유 자원에 접근할 때 스레드간 동기화 작업이 필요하다. 하지만 이러한 동기화 작업으로 인해 병목현상이 발생하여 성능이 저하될 수도 있다.

• 멀티프로세스는 하나의 프로세스가 죽더라도 다른 프로세스에는 영향을 끼치지 않고 수행된다는 장점이 있지만 (카톡하다 오류 발생했다고 틀어놓은 멜론 노래가 꺼지진 않듯이) 멀티스레드는 하나의 스레드가 죽으면 전체 스레드가 죽을 수 도 있음.

멀티스레딩과 멀티프로세싱 이 두가지는 동시에 여러가지를 수행한다는 점은 같지만 시스템에 따라서 적합 부적합이 갈린다 --> 적합한 방식 선택 ㄱㄱ

멀티코어프로그래밍

하나의 작업을 위해 여러개의 cpu 코어를 활용하기 위해 코드를 작성하는 작업

Parellelism(병렬성) vs Concurrency(동시성)

• 동시성 : 동시에 실행되는 것 "처럼 보이는것"
  • 싱글코어, 멀티코어에서 가능
• 병렬성 : 실제로 동시에 실행되는 것
  • 멀티코어에서 가능
  • Data 병렬성, Task 병렬성

    동시성

    

    병렬성

    

싱글스레드 프로세스 & 멀티스레드 프로세스

다음은 번외로 프로세스, 스레드, 멀티태스킹, 멀티스레딩, 멀티프로세싱, 멀티프로그래밍 총정리 ㄱ

접근

시행착오 1

처음에 문제를 보자마자 그전의 기출을 통해 그리디 알고리즘으로 해결해야 하는 문제인것은 캐치하였으나, 그 이후로 나아가질 못하였다. N의 최대 크기가 2000인 점에서 완전탐색도 어느정도 염두해 두고 문제를 해결해나갔어야 했는데, 그 부분까지 도달하지 못하여 작업을 하나씩 꺼내서 순회하는것을 생각하지 못하였고, 이틀에 걸쳐서 문제를 풀게 되었다. 쉬운 문제라고 생각했는데 역시 카카오 문제가 쉬울리 없지 ㅠ

시행착오 2

for i in range(len(N)):
    count=0
    pres,pree=N[i][0],N[i][1]
    for j in range(len(N)):
        ns,ne=N[j][0],N[j][1]
        if ns<pree+1000:
            count+=1

안일하게 완전탐색으로 N*N으로 계산하였으나 저렇게 작성하면 오류가 발생함. 후반 인덱스로 갈수록 e가 커지기 때문에. ns<pree+1000 이부분이 무조건적으로 참을 반환할 확률이 다분하게 커지기 때문에, 다음과 같이 수정해주어야한다.

for i in range(len(N)):
    count=0
    pres,pree=N[i][0],N[i][1]
    for j in range(i,len(N)):
        ns,ne=N[j][0],N[j][1]
        if ns<pree+1000:
            count+=1

시행착오 3

배열을 순회하는 과정에서 겹치는 작업을 계산할 때 부등호를 ns<=pree+1000 로 작성하였었는데 해당 부분에 오류가 있었다. 왜냐하면 작업은 시작시간과 끝 시간이 포함이므로, 어떤 작업이 끝나자마자 다시 시작한다고 하였을때 count는 1이 되어야 하는것이 정상이지만, 해당 ns<=pree+1000 로직으로 계산하였을 경우 count가 2가 되기때문에 다음과 같이 ns<pree+1000로 수정해 주어야 한다.

전체 코드

def solution(lines):
    N=[]
    maxval=0
    for line in lines:
        line=line.split()
        hms=line[1]
        hms=hms.split(":")
        tosec=int(hms[0])*3600+int(hms[1])*60+float(hms[2])
        tomil=int(tosec*1000)
        spent=int(float(line[2][:-1])*1000)
        start,end=tomil-spent+1,tomil
        N.append([start,end])
    for i in range(len(N)):
        count=0
        pres,pree=N[i][0],N[i][1]
        for j in range(i,len(N)):
            ns,ne=N[j][0],N[j][1]
            if ns<pree+1000:
                count+=1
        maxval=max(maxval,count)
    return maxval

참고

데이터의 갯수가 충분히 작을때는 항상 브루트포스 염두해 두길